Threaded Render Module

For help with anything that CEGUI doesn't offer straight out-of-the-box, e.g.:
- Implementation of new features, such as new Core classes, widgets, WindowRenderers, etc. ...
- Modification of any existing features for specific purposes
- Integration of CEGUI in new engines or frameworks and writing of new plugins (Renderer, Parser, ...) or modules

Moderators: CEGUI MVP, CEGUI Team

Toadcop
Not too shy to talk
Not too shy to talk
Posts: 23
Joined: Mon Sep 06, 2010 18:13

Threaded Render Module

Postby Toadcop » Fri Sep 24, 2010 13:05

So i have played a bit with CEGUI and have found out what i need it in my logic thread (the renderer is in other thhread and i send messages to change it states (create, move, etc) via circular buffer well w/e)
as i see the only good way to overcome this (thread safety) is to rewrite render module.

my questions are:
1) does CEGUI every frame create new objects and so on ? (rectangles etc) so will it generate alot objects to sync ?
2) are there some specific internal "hacky" functions ? which also may produce some problems. (for example automaticly adding frame listener.)

why i need/want this.
it's because i have found out what it would fit much better if Lua script module would be available in logic thread (so i could potentialy read any objects data with out problems) and so allow much more flexible GUIs. this is actually the main reason and the second is what i actually allready sync input events for CEGUI from logic thread (so i would just don't need it)
ofc there are also some drawbacks in having GUI procesed in logic thread. but they are minor.

a had a look at the render module sources and it seems to be relative "simple"...
I havent analyzed CEGUI well and thats why i have this question. is CEGUI working efficient with render objects ? (potential data to sync)
tnx.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Threaded Render Module

Postby CrazyEddie » Mon Sep 27, 2010 13:05

Ok, basically the CEGUI code is not thread safe in any way, shape or form. If something works when doing CEGUI things on separate threads it's by accident and not design.

To answer the specific questions:
1) We're not generally allocating / creating loads of things every frame. Mostly buffers and such are created, populated and only modified when it's necessary due to some window(s) changing either state or having their visual representation invalidated.
2) No. I don't think I'd call any of the functions "hacky".

The above being said, various seemingly innocent calls may also end up calling into the renderer module - as evidenced by emarcotte's listbox issues (I must say that I think this specific case is not good, and I'd certainly like to address this one, if none of the other threading issues. Having evaluated somewhat, that fix will likely be an 0.8.0 thing, as would any other changes in this area).

CE.

Toadcop
Not too shy to talk
Not too shy to talk
Posts: 23
Joined: Mon Sep 06, 2010 18:13

Re: Threaded Render Module

Postby Toadcop » Mon Oct 25, 2010 23:10

hmmm after some time of lazines =) i encoutered the problem what.
CEGUIOgreTexture - is actaully a render object BUT need to know texture info and so on. so it mix logic\render
i mean texture as it self is a render object (color pixels) and not object of logic
my question is how much dependent is CEGUI on texture as "logic" object ? (not as element to draw) to make it more clean. i want to load the texture in different (render ) thread so it wont stop logic from working case ogre works in locking mode (thread is waiting) if you load resource.
with GeomtryBuffer almost all is clear and can be separated nicely. but with Textures i have no idea for now...

the goal is to "fully" separate calculating and drawing stuff

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: Threaded Render Module

Postby Jamarr » Tue Oct 26, 2010 17:35

This has been discussed before, see this thread. As you found out, the System::renderGUI() call can modify state in various sub-processes, and apparently some logic-processes can call the renderer. Ideally these processes could be refactored to separate the logic/state changes from actual rendering (as you mention), perhaps via a System::updateGUI() call or some such.

If you really want this your best option will be to dig into CEGUI's source and refactor the rendering process yourself. As the source code is available, it should not be too difficult to determine what state-changes are made to the textures during rendering or resource-loading - and then determine how to cleanly separate them. I know you wanted specific details on Textures, but unless someone else takes a fancy to this issue you'll have to look at the code yourself.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

Toadcop
Not too shy to talk
Not too shy to talk
Posts: 23
Joined: Mon Sep 06, 2010 18:13

Re: Threaded Render Module

Postby Toadcop » Tue Oct 26, 2010 18:16

yeah but the essential draw back of changing source is loosing compability and i will need allways to recompile (modify) source of new (bug fix etc) releases. but i see what you mean thanks alot !

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Threaded Render Module

Postby Kulik » Tue Oct 26, 2010 18:18

You could make a patch and if it isn't breaking existing code and is of good quality, it could get accepted into CEGUI releases... I think CE even created some tickets in mantis regarding this separation so chances are this gets accepted...

Toadcop
Not too shy to talk
Not too shy to talk
Posts: 23
Joined: Mon Sep 06, 2010 18:13

Re: Threaded Render Module

Postby Toadcop » Mon Nov 22, 2010 18:31

well i managed to go around, with out modifing cegui core. everything seems to be relative "ok" but now i have major problem. and i hope someone can help me to clarify it.
as i can understand it's all about Ogre Viewports (my current problem). i will now try to explain step by step what is happenening.
1) first of all NO gui at all is showed but evething else is rendered properly.
2) and before i don't remove some lines in ogre render module from it's logic it will continue to be so.
3) after i remove all operations (2) in ogre render module where it sets the viewports

Code: Select all

void OgreRenderTarget::activate()
{
    if (!d_matrixValid)
        updateMatrix();

    if (!d_viewportValid)
        updateViewport();

    [b]d_renderSystem._setViewport(d_viewport);[/b] // <- this is major one
    d_renderSystem._setProjectionMatrix(d_matrix);
    d_renderSystem._setViewMatrix(Ogre::Matrix4::IDENTITY);
}


4) it begin to render gui, but ONLY if i move cursor over an element with a tooltip (and afer 1-2 seconds it dissapper)
5) when GUI is rendered for short time the other (main) scene is not rendered at all ("standing still")
6) if i set focus to some element of gui (select a text box) it will render the GUI and the main scene in the area of this selected viewport (and this element will not be drawed. it seems to be just as a viewport for the scene)

so as i understand every element of gui in cegui use kind a own viewport to draw it ? and what should be the proper oder/logic beyond it ? for now i couldnt figure it out.

also i use manual render in Ogre by calling
mRoot->_updateAllRenderTargets()

the gui should be drawed after this call as i understand ?
every help and info/hints are very appreciated.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: Threaded Render Module

Postby CrazyEddie » Wed Nov 24, 2010 11:42

For the Ogre based CEGUI renderer, a view port is not used per widget, but per render target. It is required so that things are rendered correctly for the specified target (i.e the display vp will differ from a vp used for a render texture, and each render texture will additionally differ based on it's dimensions).

A render target in the CEGUI sense is not the same as an Ogre render target, and so the Ogre "_updateAllRenderTargets" call will not cause CEGUI rendering to be updated, as far as I understand it.

CE.

Toadcop
Not too shy to talk
Not too shy to talk
Posts: 23
Joined: Mon Sep 06, 2010 18:13

Re: Threaded Render Module

Postby Toadcop » Thu Nov 25, 2010 21:41

ok the thing i missed was to swap buffer. now it works but it get slightly flickers
related to viewtopic.php?f=10&t=4992&p=25307#p25307
i think the reason for it is what it may happen what 2 (or more) CEGUI updates are done on 1 render update. or would this usualy not affect this at all ? (cause potential overlaping of the same widgets)
i have the feeling what i get doubled widgets (on the render side) so objects with transparency get more dark (opaque) = flickers.
any hints how to handle such cases ? (several cegui updates against only 1 render update)


Return to “Modifications / Integrations / Customisations”

Who is online

Users browsing this forum: Bing [Bot] and 9 guests