Anders Runesson wrote:
> fre 2006-07-28 klockan 12:21 +0200 skrev freeagle:
> 
>> I already have coded something like you, singlethreaded too. But i realized its very performance limiting when you try to open more than one openGL window in a single thread. Switching to multithreading will make the coding harder, but i think it has more pros than cons, much more. 
> Yup. But from what I hear, opengl is extremely sensitive to being called
> from different threads simultaneously. The rendering needs to be done in
> one single thread, for all windows. Anything else is apparently asking
> for trouble.
> 
> /Anders
> 
hmm, i havent found any prob on the net when using context-per-thread-per-window approach. People only mention there is a problem when you try to draw to a single context from multiple threads, or drawing to the same window using multiple contexts from different threads. And im not planning to do that. And if possible, prevent the user from doing it as well. But if you found something else, plz, post a link to that article, id like to read it.

fre 2006-07-28 klockan 13:50 +0200 skrev freeagle:

> hmm, i havent found any prob on the net when using context-per-thread-per-window approach. People only mention there is a problem when you try to draw to a single context from multiple threads, or drawing to the same window using multiple contexts from different threads. And im not planning to do that. And if possible, prevent the user from doing it as well. But if you found something else, plz, post a link to that article, id like to read it.

I have never tried it myself, I just repeated something I heard. People ask about threads often on comp.graphics.api.opengl, and often people answer "be careful about threading with opengl!". But you are probably right, it's single context-multiple threads that cause worries.

/Anders

freeagle wrote:
> Brad Anderson wrote:
>> Kramer wrote:
>>> clayasaurus wrote:
>>>> freeagle wrote:
>>>>> Hello D community.
>>>>>
>>>>> I joined a while ago a talk at d.D.dwt about future of DWT and other
>>>>> possible GUI toolkits. There were many opinions, but there was one
>>>>> that I liked the most - making a cross platform GUI library that
>>>>> would use OpenGL as a renderer. I know there was a project called
>>>>> Terra, but it seems that it went down. So i decided i could make
>>>>> something similar. It would be multithreaded lib from ground up
>>>>> because of the way openGL works with multiple windows. I dont want to
>>>>> make any official announcement of a development taking place until I
>>>>> ask the D community if it would welcome such effort. And what would
>>>>> you like it to be capable of. I have my own ideas, but i dont want to
>>>>> make something that pleases me, but will be refused by majority of
>>>>> the devs.
>>>>>
>>>>> freeagle
>>>> Terra is still alive and well http://www.sequenceartworks.com/labs/terra/
>>>>
>>> The DSource project no longer seems available.  Is it still being
>>> actively developed, or just in hiatus...?
>>>
>>> -Kramer
>>
>> Soon, Trevor will re-release under a different project, and Terra will be a
>> sub-project.  That's if I understood him correctly.
>>
>> BA
> 
> do you know how far is he with the development? because at dsource, Terra seemed to be untouched for quite a while

All I know is that he does actively develop it outside of dsource.
~ Clay

freeagle wrote:
> Hello D community.
> 
> I joined a while ago a talk at d.D.dwt about future of DWT and other possible GUI toolkits. There were many opinions, but there was one that I liked the most - making a cross platform GUI library that would use OpenGL as a renderer. I know there was a project called Terra, but it seems that it went down. So i decided i could make something similar. It would be multithreaded lib from ground up because of the way openGL works with multiple windows. I dont want to make any official announcement of a development taking place until I ask the D community if it would welcome such effort. And what would you like it to be capable of. I have my own ideas, but i dont want to make something that pleases me, but will be refused by majority of the devs.
> 
> freeagle

That would be pretty nice, especially being cross-platform and OpenGL
based, which I particularly like.

Since it is cross-platform, how are you planning to handle the OS
specific code? Write it yourself or re-use some code? Because it seems
to me it is much and unnecessary work to do it yourself, perhaps you
should use a cross-platform rendering lib, such as SDL or maybe Cairo ?
SDL seems a favorite for me, it the most abstracted one as it is only a
media layer library, it does not have 2D shape rendering stuff like
Cairo. But there are some problems: SDL currently (1.2) allows only one
GL context, which goes against your objectives of multiple windows, and
that has been a prominent disadvantage of SDL so far. (it was too
mentioned here in the newsgroup previously, when there were talks about
a common D media layer lib)
However, the 1.3 version of SDL, which is under development, will fully
support managing multiple GL contexts, so I think SDL would be great as
a GUI base rendering layer. I don't know however, is when it is expected
that SDL 1.3 will come out, if there is even such an estimate. (but
you're starting out yourself, so maybe it is worth it)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> freeagle wrote:
>> Hello D community.
>>
>> I joined a while ago a talk at d.D.dwt about future of DWT and other possible GUI toolkits. There were many opinions, but there was one that I liked the most - making a cross platform GUI library that would use OpenGL as a renderer. I know there was a project called Terra, but it seems that it went down. So i decided i could make something similar. It would be multithreaded lib from ground up because of the way openGL works with multiple windows. I dont want to make any official announcement of a development taking place until I ask the D community if it would welcome such effort. And what would you like it to be capable of. I have my own ideas, but i dont want to make something that pleases me, but will be refused by majority of the devs.
>>
>> freeagle
> 
> That would be pretty nice, especially being cross-platform and OpenGL
> based, which I particularly like.
> 
> Since it is cross-platform, how are you planning to handle the OS
> specific code? Write it yourself or re-use some code? Because it seems
> to me it is much and unnecessary work to do it yourself, perhaps you
> should use a cross-platform rendering lib, such as SDL or maybe Cairo ?
> SDL seems a favorite for me, it the most abstracted one as it is only a
> media layer library, it does not have 2D shape rendering stuff like
> Cairo. But there are some problems: SDL currently (1.2) allows only one
> GL context, which goes against your objectives of multiple windows, and
> that has been a prominent disadvantage of SDL so far. (it was too
> mentioned here in the newsgroup previously, when there were talks about
> a common D media layer lib)
> However, the 1.3 version of SDL, which is under development, will fully
> support managing multiple GL contexts, so I think SDL would be great as
> a GUI base rendering layer. I don't know however, is when it is expected
> that SDL 1.3 will come out, if there is even such an estimate. (but
> you're starting out yourself, so maybe it is worth it)
> 

I plan to write OS specific code myself. Whether it's more work or not is questionable. In SDL, you'd have to write child window logic yourself. But in my lib, child windows are normal OS windows ( in Win32 WS_CHILD ) and thus every control logic is done by the OS. These child windows are transparent, so all OGL rendering is done just on the main parent window.

freeagle wrote:
> ... And what would you like it to be capable of. I have my own ideas, but i dont want to make something that pleases me, but will be refused by majority of the devs.
> 

I've been toying with the same idea (OpenGL GUI), but I haven't got around to thinking about it too much...

I think it would be great to have the GUI library flexible enough that it could be used in a 3D engine but at the same time be usable in a stand alone application. Of course the main problem is that 3D engines usually want to control all OpenGL calls to make the rendering as efficient as possible.

I've also had some ideas for flexible transition effects, so I'm interested to hear how you envision this part of the system. But that can be discussed later...

Lucas

Lucas Goss wrote:
> freeagle wrote:
>> ... And what would you like it to be capable of. I have my own ideas, but i dont want to make something that pleases me, but will be refused by majority of the devs.
>>
> 
> I've been toying with the same idea (OpenGL GUI), but I haven't got around to thinking about it too much...
> 
> I think it would be great to have the GUI library flexible enough that it could be used in a 3D engine but at the same time be usable in a stand alone application. Of course the main problem is that 3D engines usually want to control all OpenGL calls to make the rendering as efficient as possible.
> 
> I've also had some ideas for flexible transition effects, so I'm interested to hear how you envision this part of the system. But that can be discussed later...
> 
> Lucas

exactly, that's what I'd like to achieve. Making the lib usable for both apps and games, making the widgets universal ("Universal" is actually the name I'd like the lib to have) for both of them. No need to write widget logics again and again, just skin the controls using different theme.

Lucas Goss wrote:
> freeagle wrote:
>> ... And what would you like it to be capable of. I have my own ideas, but i dont want to make something that pleases me, but will be refused by majority of the devs.
>>
> 
> I've been toying with the same idea (OpenGL GUI), but I haven't got around to thinking about it too much...
> 
> I think it would be great to have the GUI library flexible enough that it could be used in a 3D engine but at the same time be usable in a stand alone application. Of course the main problem is that 3D engines usually want to control all OpenGL calls to make the rendering as efficient as possible.
> 
> I've also had some ideas for flexible transition effects, so I'm interested to hear how you envision this part of the system. But that can be discussed later...
> 
> Lucas

BTW, that problem you mentioned can be solved like this: application and windows has their own threads. It could be possible to use the window thread just for message handling, with no GL calls. Then acquire the context of that window in the application thread and make it handle all rendering (first the world and then tell the contained widgets to render themselves) and game mechanics.

I have also thought about doing this kind of library OpenGL+SDL based. Terra seemed to show no more sign of activity. However, before starting to code anything, I searched the web to find if anyone had already tried to do the same in C, since it is binary compatible with D.

I found two libraries that interested me ( I no longer remember why there were especially interesting ):
- Agar: http://agar.csoft.org/index.html.en
- OTK: http://otk.sourceforge.net/

I had several ideas about using these :
- making a binding to D.
- wrapping the functions and structures into a hierarchy of D classes.
- making my own library, using the code as a template to rely on a 	 proven design. That latter idea is too much unrealistic for me, all alone, but you may find it usefull.