GUIX MULTI_LINE_TEXT_VIEW Corrupts drawing the main window when in a parent window (sometimes)

I am experiencing some odd behavior with this.

I have an object called Text. It consists of a window with a text_prompt and a multi_line_text_view object. When I attach it to my main window everything is fine.

Text (window)

   - text_prompt

   - multi_line_text_view

 

I have another object called Panel. It consists of a window with a text_prompt and a child window called Scrollbar. This child window has a scrollbar attached and its own child window called Content. The scrollbar then scrolls the Content window. I attach the Panel to my main window and fill it up with other widgets everything works great.

Panel (window)

  - Scrollbar (window)

      - Content (window)

          - various widgets

 

Then I add a Text object to the Panel.

Panel (window)

  - Scrollbar (window)

      - Content (window)

          - Text (window)

            - text_prompt

            - multi_line_text_view

 

And things go weird. It looks like drawing the multiline view corrupts the dirty rect that controls how much of the screen is drawn. 

When the window is first opened, only parts of it draw - typically those widgets attached before the Panel. If I then touch the Text object in the panel, the rest of the panel is drawn. If I touch the main window to generate a FOCUS_GAINED event, the whole page gets drawn.

If I redefine Text to put its widgets in a window, which is then added to the Text window (i.e. if I add  layers of windows to the Text object before it gets to the multiline view widget) it works perfectly fine when attached to the main window (as expected - the extra layers of windows do nothing). But when attached to my Panel object, the drawing behavior gets even more bizarre; two layers of windows, for instance, means the main window draws when opened but the multiline textview does not; touching it then draws it but erase the rest of the main window.

I cannot figure out what is different about attaching this Text window with its multiline widget to my main window vs my Panel window, save for the scrollbar. But detaching the scrollbar from the panel doesn't change anything.

Any ideas?

  • Hi MCP,

    How's this issue? Have you made some progress or were you able to solve this already?

    JB
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    https://en-us.knowledgebase.renesas.com/

  • In reply to JB:

    I have not made progress. However, I have learned a bit more.

    There seems to be something wrong with multi line text view. I already described the problems I had when putting one several window layers deep. But the problems are worse than that.

    Right now I have a multi line object taking up half my screen (and directly attached to my main window). It's displaying about 500 characters. And it suffers the same problem: touching the screen causes text to disappear and appear at random.

    It always draw the first part of the text. And if I scroll the view so that less than 300 or so characters are showing, it seems pretty reliable (though not if it is several windows deep, as above; then even short text can fail).

    It looks like the text rendering function just can't keep up, although I am not entirely sure why a FOCUS_GAINED event for my main window would even cause a multi line text object to update.

    I have now reduced my screen to a multi line text view and a single icon button. And it very reliably alternates between drawing all of the text and just drawing the first 60 characters or so whenever I touch the main screen area (nothing changes when I touch my button).

    It really looks like either a) multi line text views can't handle very much text, or b) they are doing something weird to the dirty rect.

    So I have two questions:

    1) how do I get a multi line view to stop redrawing itself in response to main window events that have nothing to do with it?

    2) It seems to often fail when asked to draw 300+ characters. Is there some kind of limit? Is there a way to increase that limit?
  • In reply to MCP:

    If I call gx_system_dirty_mark (MainWindow); ten times a second... it doesn't help. If the text is completely displayed, it remains completely displayed. If it is not, it remains that way. Until I touch the screen and generate another FOCUS_GAINED even for my main window. Then it switches.
  • In reply to MCP:

    I still can't figure this out. It happens when FOCUS_GAINED causes a buffer switch. For some reason, the buffer has not had all of the text drawn. I have stepped through the code and watched it write each glyph into memory, so I really just do not understand what is happening.

    I will try to put together a simple project that displays this bug, when I get a chance.
  • In reply to JB:

    Can you please send me a Hello World project for IAR for the S7G2 EPE-HMI1 that works? I have SSP version 1.6.0, but the Hello World project I have fails to compile with this error:

    Error[Pe513]: a value of type "void (*)(GX_DRAW_CONTEXT *, INT, INT, INT, INT, INT, GX_PIXELMAP *)" cannot be assigned to an entity of type "void (*)(GX_DRAW_CONTEXT *, INT, INT, INT, INT, INT, GX_FILL_PIXELMAP_INFO *)"

    I honestly have no memory of how I got my current project to function, but I do not want to reverse-engineer it back to the minimal possible footprint just to show you this problem.
  • In reply to JB:

    I simply put in a hard cast to get the thing to compile. Now I can send you a Hello World program that demonstrates the problem. When you repeatedly touch the main window (not one of the widgets) you will see the multi line text view alternating between complete or with one and half lines missing from the end.

    Please let me know how to send you this project so you can see it for yourself.
  • In reply to MCP:

    Or you could open your Hello World, add a mult-line text view in the lower left quarter, and type in several paragraphs of text with some carriage returns so that it more than fills the box. and see if you get the same behavior.
  • In reply to MCP:

    Hi MCP,

    If you are using the D/AVE 2D accelerator please check the the Work memory size for display lists in the properties of the D/AVE 2D port on sf_tes_2d_drw. The default is 32K and may not be large enough for a large multi line text view if you have many other things also being rendered. Try increasing this to 64K.

    -Gary
  • In reply to garyj:

    I contacted Express Logic and they mentioned the same thing. (BTW they are really helpful; it reflects well on Renesas that they picked such a good partner).

    Increasing the work space to 524K (when I tried 1024K the linker complained) in the SSC Configurator in the properties of the "D/AVE 2D Port on sf_tes_2d_drw" module solves the problem for Hello World, but not for my actual application which may display 2 or even 3 multi line text views at the same time. This strikes me as highly surprising; I would have expected that much work space to be sufficient for any amount of text. There seems to be a weakness in Renesas' port of the 2D driver.

    Turning off the hardware 2D engine from GUIX Studio / Configure / Projects/Displays / Advanced Settings does work, however. Now I can have 3 multi line text views on the screen and everything is fine. This does mean I don't have hardware acceleration but I don't think I need it; I'm not displaying any images. Obviously I would like it fixed but I can deal for now.

    However... there is still the original issue. When I bury the multi line text view in enough layers of windows, I get the same results: some widgets not drawing or the text view cutting off mid-sentence whenever a FOCUS GAINED event hits the main window.

    It is really odd that two entirely different issues - hardware acceleration and window depth - produce the same random behaviour.

    Again, for now, I can deal - I just limit the window depth for my text views and for now that's good enough - but I would like to get to the bottom of this, in case my requirements change or just for peace of mind in general. I will let you know if Express Logic has anything to add about the window depth.

  • In reply to garyj:

    (Note: 32K isn't big enough for the Hello World project, which displays 3 text buttons.)
  • OK, I have a definitive answer.

    I had actually uncovered two issues.


    1) Renesas' hardware acceleration port is problematic. 32K working memory isn't even for a simple example with 3 text buttons and a multi-line text view. No amount of working memory seems to work for any more complex example. You can turn off hardware acceleration via "GUIX Studio / Configure / Projects/Displays / Advanced Settings." You can probably also turn it off in the SSC under the properties for "GUIX on gx", but I haven't tested that and I don't know how it interacts with the GUIX Studio setting.


    2) GUIX tries to keep a small footprint. Express Logic told me where to make it more robust, at the cost of GUIX requiring more static memory. Go to these two files and change these constants:

    gx_user.h
    #define GX_MAX_DIRTY_AREAS 128 // 64 default
    #define GX_MAX_CONTEXT_NESTING 32 // 8 default

    gx_port.h
    #define GX_MAX_VIEWS 128 // 32 default

    You can probably get away with just changing the content nesting and max views, but I went ahead and increased everything because why not. Also you can experiment with different numbers to minimize space vs support your coding style.

    The only problem with this approach is that regenerating the SSC project content also regenerates these files, so you have to remember to go back and change them by hand. I couldn't find anywhere where the SSC would let me adjust them inside of it, so I have also defined the constants in my main program file so that if I regenerate and forget to change them, I will at least get a compiler warning that the two definitions don't match.

    Remember that you have to do Rebuild All whenever you change these values, to recompile the GUIX system.
  • In reply to MCP:

    For point 1) you will need to disable the Dave2D acceleration in both places, in the GUIX Studio project, and in the Synergy project.

  • In reply to Jeremy:

    That hasn't been my experience. Turning it off at the GUIX Studio level makes everything work.

    When you turn off/on the 2D engine from GUIX Studio, it rebuilds all your bitmaps and font glyphs (presumably because they are in a different format for acceleration). If there is more acceleration happening beyond that, I guess I'm fine with it, since it's not showing any bad behavior - yet. I'll keep this in mind in case things start going wrong after I add more widgets to the screen.

    There still seems to be something wrong with the 2D engine, though, given that it can't support a single multi-line text view in the Hello World application with the default settings. Perhaps it's just the glyph drawing acceleration that is weak?

    Does anybody know how to kick this up to Renesas for official consideration? I've always gotten all of my help through the forum.