Nested window draw incorrectly when frame resized

[Armitage1982]

Oh yes sorry !

As you say :
- The Alpha Blending varie when set and unconsistent in text field
- FPS is slower than without the AutoRenderingSurface enabled
- I can't use the new string tags (but maybe this is due to missing methods in the wrapper, I didn't see any reliable documentation on this).
- While hovering The close button of my framewindows this button appears 2 times in row (I suppose it's due to the fix I need to do with the layout but at least this one wasn't there in 0.7.0).

I think it's all.
What I'm more preoccupied with is the slow down
Even if I successfully fix every layout, can use tags and if the alpha problem is fixed I'm not sure I will trade 110fps since my game can run on pretty old system right now and I like that fact.

Can I help you in any better ways ?

[CrazyEddie]

No, no. You previously seemed to be suggesting that there were many people posting here with a set of common issues - especially in relation to the activation of texture targets (i.e. with AutoRenderingSurface enabled), so much so in fact, that you appeared reluctant to enable the setting. The issues you mention - while applicable to your specific situation - are not commonplace at all.

I'm not sure if what you describe in relation to alpha is the same issue I'm talking about - especially given the last part about inconsistent in text fields. The issue I was referring to only happens on windows that are first rendered to texture and manifests itself as a kind of bleed-through. Anything else is not the same issue and is unrelated.

In relation to the performance issue, the only thing I can think of that is likely to cause such a slowdown - especially one that gets worse with texture targets in use - is if something is happening within the app that short-circuits / continually invalidates the caching of window content (geometry in general, and intermediate output in the case of texture targets) every frame (such as calls to functions named requestRedraw, signalRedraw, invalidate, and so on and so forth).

The string tags are enabled by default, you do not need to do anything special to use them. The lack of documentation is fair comment, in my defence, alas, I did not yet get the surgery to attach a second pair of hands

I don't know anything about the last issue - it sounds totally app dependent to me.

CE.

[Armitage1982]

I was referring to :
viewtopic.php?f=10&t=4425&p=20674&hilit=AutoRenderingSurface#p20674
and
viewtopic.php?f=10&t=4388&p=20521&hilit=AutoRenderingSurface#p20521
and
viewtopic.php?f=2&t=4547&p=21217&hilit=text+transparent#p21217

Which is probably the same problem.

I don't have any requestRedraw, signalRedraw in my code but I can't tell about the wrapper.

About the string tags parser :
I'm loading my text from a locale database at runtime (I'm nearly sure it's not the problem) but isn't this working this way ?

Code: Select all

.setText("This is my text [colour="FF00FFFF"]coloured in red[/colour] or something")

Of course I understand about the documentation

What about the 'Non-Client' error in my log file ?
Is this normal ?

Thanks CE

[CrazyEddie]

Hi,

The first topic linked is highly likely to be the known alpha problem. This is just a single issue.
The second topic linked is totally unrelated, the poster indicates they're not using texture targets; the issues they were having should all now be fixed. If anyone still has those issues they should (re)report them.
The third topic linked is definitely the known alpha problem. Again, it's just that single issue.

I have to apologise, because I'd missed your log file It appears your issues are stemming from this:

Code: Select all

13/12/2009 18:05:26 (Std)    ---- CEGUI System initialisation completed ----
13/12/2009 18:05:26 (Std)    ---- Version 0.6.2 ----
13/12/2009 18:05:26 (Std)    ---- Renderer module is: CEGUI::OpenGLRenderer - Official OpenGL based renderer module for CEGUI ----
13/12/2009 18:05:26 (Std)    ---- XML Parser module is: CEGUI::TinyXMLParser - Official tinyXML based parser module for CEGUI ----
13/12/2009 18:05:26 (Std)    ---- Scripting module is: None ----


The version is indicating you're not even running the 0.7.x code! Please tell me you have not been wasting my time

With regards to the tags, they act as state settings, rather than BBcode-like tags, so for example you might do:

Code: Select all

.setText("This is my text [colour='FF00FFFF']coloured in red[colour='FFFFFFFF'] or something")

This sets the colour to yellow, then back to white. Note the order of the elements is AARRGGBB; the same as for colour properties. Not also the use of single quotes. Of course this will not work if you're running 0.6.2.

CE.

[Armitage1982]

The version is indicating you're not even running the 0.7.x code! Please tell me you have not been wasting my time

Oups my apologizes !
I mess-up with the old and newly log (I switch very often these days) present in different folder.
But I'm sure I was using the 0.7.1 code or then I wouldn't report the alpha problem
Here is the actual Version 0.7.9999 log file : http://www.mediafire.com/?0zzjmzw3ygt

About the tags I wrote that example on the fly (since importing my string from xml). It's true that it would not have working this way with double quote
I try to test with single quote in my locale database but the text isn't processed (but don't worry too much it's probably because I'm missing something).

[CrazyEddie]

Oooh, SVN trunk brucey is a brave man

Ok, we can see from the log that everything should be working fine as far as rendering goes, so we come back to that issue of subverting the caching. The reason it 'has to be this' (i.e. the caching issue), is for the following reason...
If you have a FrameWindow + content that amounts to say 2000 triangles, after the first rendering pass (when the imagery is cached), unless anything changes on that FrameWindow, for subsequent renders it will only need to set 1 texture and draw 2 triangles (saving 1998 triangles, and many, many state changes). So you can see that when used correctly, it's pretty much impossible that the use of the texture based rendering surfaces would be slower. This means that the caching is being subverted and thus creating more work, hence it's running even slower. I'm tempted to get BlitzMax so I can try the thing out for myself!!

With regards to text tags, so it's not working, but what do you see? And also, what is the type of window you're trying to set this for (because for instance, it will not work on Editbox types by design).

CE.

[Armitage1982]

I'm using this in a ... readonly MultiLineEditorbox... I though it was ok (I was intented to write the documentation of my built in level editor with image and enhanced presentation). "... so my text is [colour='FF00FFFF'] like this ...".

About the speed it's basically what I was waiting for.
I see now why you having so much difficulties with blending
But since I wasn't using the subverting cache at first (frameWindow wasn't set for AutoRenderingSurface), I wonder if the slowdown really come from this ?

[CrazyEddie]

Ah, well... The editbox is why you get no colours then You should be able to swap that out for a static text - enable the scrollbars on that and the results should be pretty similar.

There's definitely a high likelihood that if something is causing the caching to become useless, this would also affect things when not using the AutoRenderingSurface. This is because we're additionally caching the actual geometry for each window - so unless the content changes in some way, the geometry is re-used from the cache (GeometryBuffer) - so for example no calls to Imageset::draw or Font::draw are made in these conditions, again with really big savings. However, if something causes the cached data to be regenerated each frame, obviously this causes a substantial hit instead. At the moment, this is the only logical explanation - though one with an unknown cause.

CE.

[CrazyEddie]

Ok. I am now the proud owner of BlitzMax

I've tested out the CEGUI rendering (by way of adding some additional logging), and can confirm that under those normal circumstances, the rendering is being done correctly. If you're interested in temporarily adding that extra logging to see if you get the correct behaviour also, let me know and I can put a patch up here. Or if you want to send me something that demonstrates the issue you have, that would be fine also...

CE.

[CrazyEddie]

An additional FYI: Today I have fixed the alpha blending issue that was affecting the output when using texture targets, so next time brucey updates that fix should get picked up.

CE.

[Armitage1982]

Thanks a lot CE !

Sorry, I was not available this week.
Well I don't think I have wrong behaviour, only a small slow down since 0.6.2
If you still want to check that difference the Brucey SVN Module for CeGUI 0.6.2 is Revision 783.

I will wait the next update from Brucey in order to test the new fix

[CrazyEddie]

Thanks, some time I will test out the 0.6.2 version and see if there's any difference.

CE.

[Armitage1982]

Ah, well... The editbox is why you get no colours then You should be able to swap that out for a static text - enable the scrollbars on that and the results should be pretty similar.

I try your solution tonight but :
[*] setProperty("BackgroundColours", "tl:FF000000 tr:FF000000 bl:FF000000 br:FF000000") doesn't do anything (background stay white), probably my looknfeel is too old ?
[*] My help documentation is pretty big and only a few lines of text are visible while inside editable textbox everything was
[*] Feedline are no more effective, this break the current text layout heavily : any way to set this back ?
[*] The horizontal and vertical scrollbar (set to true) only appear when I change the size of the window. Many window using scrollbars (eg. scrollablepane) draw incorrectly at first (eg. doesn't appear like in the CELayoutEditor) but get back to normal as soon as I resize them.

Also is it possible that parent clipping has change in a way ? I disable/enable manually this feature in some combobox when they exceeds the parent window size.
This no more working with 0.7.1 (as well as some Mouse Clic event for content inside scrollablepane).

I can't help but 0.7.1 don't like me

[CrazyEddie]

Hi,

Most of what you describe should work without any issues. I've made a note locally to have a look at these issues, though it may be a few days or more.

CE.

[CrazyEddie]

I have now looked into these issues a little...

* The required elements to support background and frame colours in the looknfeel are not there, hence the fact they do not work Adding PropertyDefinition elements for those and ColourRectProperty elements within the StateImagery layer sections enables this to work.

So for example, add a PropertyDefinition to the StaticText:

Code: Select all

<PropertyDefinition name="BackgroundColours" initialValue="tl:FFFFFFFF tr:FFFFFFFF bl:FFFFFFFF br:FFFFFFFF" redrawOnWrite="true" />

Then reference it in the StateImagery parts:

Code: Select all

<StateImagery name="WithFrameEnabledBackground">
  <Layer>
    <Section look="AquaLook/StaticShared" section="background">
        <ColourRectProperty name="BackgroundColours" />
    </Section>
  </Layer>
</StateImagery>

* Not sure about this second point. I get no issues with text not appearing. Though it could be that you're not setting the HorzFormatting property (i.e so it does not word-wrap and latter parts of the text is clipped?)

* Newline / linebreaks in the text do not work if text parsing is disabled (yes, this one is a bug). Though since you want parsing, you can remove the property that disables that and get that functionality back.

* The non-appearing scrollbars does appear to be a bug also, though I will look a bit deeper into it. Also, the scrollbar definitions within the StaticText looknfeel need to have the NonClient property set to True; this does not seem to affect much for this widget type at the moment, but it could do later on

CE.