ROS performance

[ThePhysicist]

I guess most people have not run rosperf on ROS/Windows, as it isn't compiled by default.
So I post my results here.
Testing was a) WinXP 640x480x32 (vga mode) b) ROS 640x480x32 (vesa driver), c) WinXP 1024x768x32 (SiS graphics driver, just to see the difference with hw acceleration)
XP vga is alway 100%, ROS and XP hw relative to it, everything in speed!

....................XP vga........ROS..........XP hw
Fill .................100%......100,2%......1563%
Small Fill.........100%........96,7%.......936%
H. Lines..........100%........98,8%........464%
V. Lines..........100%.......191,1%.......251%
Lines..............100%.........62,9%.......238%
Text...............100%.........12,4%.......804%
Alpha Blend....100%........113,1%.....6470%
H. Gradient.....100%.......100,4%......1267%
V. Gradient.....100%.......100,2%......1266%
Gradient.........100%....unimplemented.....444%

Conclusion: ROS is quite good in most things, some are a little better (V lines is really fast), some are a little worse (Lines is not that good), but text display is really bad.
In all cases hw accelerated is a lot faster, so it is not really important if hw acceleration will be present in the future.
But I think that hw acceleration will not help much with the bad speed of text display. I think most of it is not the display, but the rendering.
I have read that there are basic (beta) cache functions in freetype. Is this already active? I wouldn't think so.
I think, this is the most important thing that makes the gui pretty slow.

something I experienced when executing the tests was, that on WinXP the mouse cursor began to make small hops, but it was alway where I had my mouse. On ROS the cursor very slowly moved around after I didn't move my mouse anymore. It was almost impossible, to hit the close button.

So my wishes for the future:
1.) Activate type caching or write an own caching system.
2.) make the mouse move as it is supposed to even with high cpu load. (more priority for the evaluation of the cursor position)

Edit: I've added the performance for gradient. Although I thought that the gradient functions looked a little unoptimized they perform quite well!

[ThePhysicist]

Hmm, nobody seems to be interested...

I have just implemented GradientFill horizontal, vertical and triangle in rosperf. I've spent most time, making it look nice
I haven't compared performance yet, but I will do later. [Edit: done, s.a.]

If one of the devs thinks, that this is a good performance test and can be put into the code, just tell me, and I'll send a patch to bugzilla.
If there are other performance tests needed, I would like to give it a try. Just let me know what's needed.

Edit: ist it normal that rosperf instantly closes, when another application in put into front?

[Nmn]

Ok, i have just found out about this post. Its extremely interesting actually.

For some reason, i also thought ros text drawing was terrible... even before this. Edit boxes with alot of content tipped me off *cough*setup*cough*

Slightly off topic, ROS has a textbox redraw problem, too(If you use tab to switch boxes and the curser is currently in a visible blink, it sticks.)

[st]

Hi.

If one of the devs thinks, that this is a good performance test and can be put into the code, just tell me, and I'll send a patch to bugzilla.
If there are other performance tests needed, I would like to give it a try. Just let me know what's needed.

Please send your patch to bugzilla and we'll see.

Edit: ist it normal that rosperf instantly closes, when another application in put into front?

Hm, I don't know. I suggest you join ros-dev mailing list and ask devs there. Not all devs read forum.

[GreatLord]

Hi

It is bad send patch to ros-dev
put it in to bugzila some will take care of it

or join on irc : freenode.net channel #reactos
u can always ask if some have time to check u code and commit it direcly
But it is not surent we devloper have time to read the patch and commit it same time u ask. but often we have time commit and read other people patcher and acpect or not.

[ThePhysicist]

Hi.

Please send your patch to bugzilla and we'll see.

Done: #1369

Edit: ist it normal that rosperf instantly closes, when another application in put into front?

Hm, I don't know. I suggest you join ros-dev mailing list and ask devs there. Not all devs read forum.

I was just too stupid When another window is in front the tests will be performed in almost no time (no drawing neccessary), and when the test is already calibrated, rosperf will almost instantly finish the test.

[logan_V8]

Hi!,
one thing that i noted when using ReactOS is that when new windows are opened they always make the mouse cursor to move slowly. There is a way to increse the mouse pointer priority?. Also, there is a way to say that ReactOS is doing something between the window drawings, such as display a busy clock as the mouse pointer?.
I am (and was) very interesting to find the causes that make ReactOS slow, but currently i don't know where to start (well, already the text drawing is slow as ThePhysicist said). Currently i'm trying to get into work the PROFILE switch .

regards,
Logan_V8

[mikedep333]

Wow, this is incredbily interesting. There are more drastic performance improvements than that with wine it seems (although that is layered on X.)

[cmoibenlepro]

Wow, this is incredbily interesting. There are more drastic performance improvements than that with wine it seems (although that is layered on X.)

It seems that reactos is still not optimized

[Ged]

It seems that reactos is still not optimized

Some parts are, Gé did some optimasation work on DIB. After his work we were about 5 times faster than XP in that area.

Most code isn't optimised though, but if Gé's results can be obtained for other parts of the code, we should leave XP in our dust.

IMO, the DIB work was an extreme case, but never say never

[geertvdijk]

It seems that reactos is still not optimized

Some parts are, Gé did some optimasation work on DIB. After his work we were about 5 times faster than XP in that area.

Most code isn't optimised though, but if Gé's results can be obtained for other parts of the code, we should leave XP in our dust.

IMO, the DIB work was an extreme case, but never say never

sounds interesting, when will optimization start? Build 0.5.0 ? That is the first version which will be quite usable I think... It's all up to the devs tho...

[ThePhysicist]

sounds interesting, when will optimization start? Build 0.5.0 ? That is the first version which will be quite usable I think... It's all up to the devs tho...

I think optimization is a medallion with two sides (I'm German, so please forgive me, if I've translated wrong).
Making a fill procedure perform very good might be interesting for people without hardware acceleration, but it is without meaning for people with hardware acceleration. That is a fact for most drawing things as you might see from the performance results. So it isn't very important to increase performance, when you support hardware acceleration. It will only be important for PCs that don't have any hardware acceleration, but those are very rare, and so it might be a waste of developers' time. But it's still important to optimize functions that can't be replaced by hardware entirely, like font rendering.
It's always good to have optimized functions, but it's only important as long as there's no hardware support that will make this obsolete. It is stupid to try to make DX software rendering functions work very optimized, when almost every graphicscard supports hw acceleration, wich wll be 100x fater!

[Wierd]

an optimized, or even prefetching glyph cache would improve a lot of things in ROS. Currently, Freetype gets called every time a glyph gets accessed. This is expensive.

If you know that a dialog box is going to call Tahoma 10 pt, you could cache all the alpha and numeric glyphs, and then pull the cached copies from the GDI heap, instead of calling freetype to rasterize the glyph each time. This would speed things up considerably.

Failing that, you could just use a 'dumb' cache, that caches commonly called glyphs.

Such caches should be global, so that all running applications can take advantage of them.


Freetype itself is not who should be performing the glyph caching. It is the win32 side that should be doing so. It currently doesnt.

[ThePhysicist]

I have looked into the FreeType code a little. The cache functions ("still beta") are there, but they have to be implemented. I thought it should be pretty easy to implement glyph caching into ROS, but the lack of documentation has made me capitulate for the moment. Can someone give me (a link for) good documentation about how to use the FreeType caching subsystem?
If I would have a basic tutorial or good documentation on how to implement this, I would try to write a patch to at least cache the FT_Render_Glyph function wich is IMHO most time consuming.
I think it would make a 0.3.0 release much better when text (like in cmd or the license text in 2nd stage setup) would be a lot faster.

I have experienced that the drawing of even empty lines in cmd.exe is pretty slow. It should be pretty fast, as there are no real glyphs to render, but it isn't. Somebody any idea why?

[GreatLord]

See Bugzila after font cache it exsist a exprement patch for caching glypth it is not complete