Show() function takes an extremely long time to execute
-
Hello,
I am running an application on Windows Compact 7. My application has been running extremely slow and I went through a lot of debugging only to find out that the time consumption was all in the show() functions for my widgets and subwindows. When I run my application on desktop Windows it runs just fine. I am unsure why the show() functions are so slow for Windows Compact 7. Does anyone know why this may be and how I can work around this?
Just some thoughts...
Does it have to do with memory? Should I increase the cache?
Does it have to do with demand paging? I shut this off for the real time performance of my application.Any thoughts or help would be greatly appreciated.
Thanks!
-
Hi rizoritis,
Do you have complex layouts or complex stylesheets/styles or a lot a of direct/indirect children or a custom widget which may take a long time drawing itself ?
Or maybe transparent widgets ?Regards,
-
[quote author="Adrien Leravat" date="1375778232"]Hi rizoritis,
Do you have complex layouts or complex stylesheets/styles or a lot a of direct/indirect children or a custom widget which may take a long time drawing itself ?
Or maybe transparent widgets ?Regards,[/quote]
I don't have any complex layouts. The most I do is giving text a higher weight. I don't have any transparent widgets. What I do have is a QMdiArea that I add about 9 custom widgets to. When I time the show() for each individual widget int he QMdiArea it takes about 1 to 4 seconds for each widget to get past the show function. Additionally, the entire UI waits for all of the functions to complete prior to drawing on the display so the cumulative time for all the show function translates to about a 30 second delay for my entire UI to be drawn. None of my individual widgets are complex at all. They mainly display text in text boxes or display data in labels. That is about it. I dont see anything as being computationally intensive.
-
I never used a QMdiArea on WEC, maybe that would interesting to see if you have the same behavior without it.
Memory/Caching may be an issue, but as you know, hidding and showing a widget is always preferred from a CPU point of view to creating/destroying, producing a lot of memory operations.
Looks like you have a bottleneck somewhere for sure. I did remember having a similar problem on a platform under WEC, but manually handling the drawing/caching didn't helped at all. One solutions that we had was to rely on OpenGL using QML/QGraphicsView, but in your case this is not an option if I'm right.
Maybe checking that the rendering engine specified during Qt configuration is the right one.I'm very interested if you find anything, but unfortunately nothing else comes to my mind for now.
From your previous thread about WEC and OpenGL, I'm not sure if you meant that you were or were "not" looking for an OpenGL enabled board. Which one is it ?
-
[quote author="Adrien Leravat" date="1375801492"]I never used a QMdiArea on WEC, maybe that would interesting to see if you have the same behavior without it.
Memory/Caching may be an issue, but as you know, hidding and showing a widget is always preferred from a CPU point of view to creating/destroying, producing a lot of memory operations.
Looks like you have a bottleneck somewhere for sure. I did remember having a similar problem on a platform under WEC, but manually handling the drawing/caching didn't helped at all. One solutions that we had was to rely on OpenGL using QML/QGraphicsView, but in your case this is not an option if I'm right.
Maybe checking that the rendering engine specified during Qt configuration is the right one.I'm very interested if you find anything, but unfortunately nothing else comes to my mind for now.
From your previous thread about WEC and OpenGL, I'm not sure if you meant that you were or were "not" looking for an OpenGL enabled board. Which one is it ?[/quote]
Ok. Thanks for the reply. I tried it without QMdiArea and it still took about the same time. My bottleneck seems to be in the .show() function. I am not sure how to get around that. Even when I just hide and show my widgets, there is still a 2 second delay per widget, minimum. I am going to try turning demand paging back on and maybe that will do something, but I doubt it.
As far as the rendering engine, how do I check if it is the right one? When I'm configuring Qt this is how I do it:
configure -platform win32-msvc2008 -xplatform wince70embedded-x86-msvc2008 -no-accessibility
And to answer your question, I AM looking for an OpenGLES enabled board for WEC7.
-
[quote author="Buckets" date="1375805553"]are you opening all these custom widgets within one form or opening multiple forms with show()? [/quote]
I am opening them all within one form. Within the form I added a QMdiArea, then created a bunch of subwindows for each custom widget. Then I added each custom widget to each designated subwindow so that I have a form with all my custom widgets in a custom "layout" (not QLayout) so that I could monitor a bunch of stuff. When I switc to different screens/views I just hide certain widgets and show others.
-
Your rendering engine is fine if you didn't overwrite it. Trying with the "raster" one may be interesting, with
@qApp->setGraphicsSystem("raster");@
There are several WEC7 board supporting OpenGL: iMX53, iMX6, OMAP4. We are making Windows Embedded Compact BSPs for boards using this processor (see "Adeneo Embedded BSPs":http://www.adeneo-embedded.com/en/Products/Board-Support-Packages)
-
[quote author="Adrien Leravat" date="1375866100"]Your rendering engine is fine if you didn't overwrite it. Trying with the "raster" one may be interesting, with
@qApp->setGraphicsSystem("raster");@
There are several WEC7 board supporting OpenGL: iMX53, iMX6, OMAP4. We are making Windows Embedded Compact BSPs for boards using this processor (see "Adeneo Embedded BSPs":http://www.adeneo-embedded.com/en/Products/Board-Support-Packages)[/quote]
I will try with raster and see how that goes. Also, we are using the x86 architecture and I believe the boards you suggested use Freescale/TI chips. Why do you not have any boards with the x86 architecture?
-
You can have a look at "Intel Atom E660 development board":http://www.intel.com/p/en_US/embedded/designcenter/tools/seed-board-program
And here is our "WEC7 Atom BSP":http://www.adeneo-embedded.com/en/Products/Board-Support-Packages/IntelARM processors are preferred to x86 on embedded devices, as they use a RISC architecture, allowing for reduced power consumption for instance.