On Sun, Aug 25, 2013 at 2:51 PM, Ludo Brands <[email protected]> wrote: > In that case, splitting the timing values between reading/rendering for > single core cpu's (the atom is single core with hyper-threading) doesn't > make sense. Rendering is very much cpu bound in this case.
Rendering the GUI must be done in the main thread anyways. Reading options from FPC does not happen at the same time with rendering the GUI. The options must be ready when the rendering starts. The reading thread starts when a user selects the "Other" page. If the user clicks "All options" then the thread has most likely finished already, but there is a WaitFor in case it has not. The beauty of this is that reading the options happens while controls on "Other" page are drawn and while the user moves his mouse towards the "All options" button. > On an i7 4 core I get Time for reading options 22ms for a total of 17ms > on console. So that suggests indeed that on a single core, the rendering > is the big problem. Yes, it is a problem. For some reason interaction with the widgetset and whatever takes lots of time. I will work on other GUI after I collect some energy and motivation. In my 233 MHz P2 machine the GUI took 9 seconds to render. Interestingly Lazarus is otherwise very usable there. I read comments on forum that Lazarus and especially GUI drawing is dead slow on Raspberry Pi although it has a faster CPU than my P2 has. It must be some display driver issue. It takes 20 secs to start Lazarus in the P2 machine. It can be still optimized I believe. Juha -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
