ROS performance

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Sun Apr 09, 2006 8:58 pm

OK, I have applied that patch to ROS. This was a little complicated. I had to do it manually, because text.c had changed too much since the patch was written. First attempt didn't work (of course ;-)). But after some time I got it working.
The fact that Royce had not experienced any speed increase, was because of a small typo, that never made the code use the cache ;-)

Code: Select all

 if (!(realglyph == NtGdiGlyphCacheGet(face, glyph_index, TextObj->logfont.lfHeight)))
should be

Code: Select all

if (!(realglyph = NtGdiGlyphCacheGet(face, glyph_index, TextObj->logfont.lfHeight)))
I have tested it on the same machine as the other tests above. The result:
Win XP: 100%, ROS: 37%. Still slow, but 3 times faster than without the patch! You can definitely see it.
I'll create a new patch for bugzilla.

GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord » Sun Apr 09, 2006 10:01 pm

Can u add that patch to bugzila
with the fix ?

I maybe will commit it

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Sun Apr 09, 2006 11:39 pm

I have attached it to the original bug report. But there's still a problem. It might be the same problem, Royce has already mentioned.
The Text under the Command prompt icon on the desktop is not drawn. It will be drawn after clicking on the icon and then clicking on another icon.
Maybe someone can find the bug. If I have time, I will try to find the bug tomorrow.

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Mon Apr 10, 2006 12:41 am

Now I know what the problem is. Some distances are measured in 1/64 pixel and some are measured in 1/1024 pixel and the calculations into pixel are messed up a bit. I got it show correctly, but it is not completely correct.
But it's late. I will try to correct these tomorrow.

Wierd
Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Post by Wierd » Tue Apr 11, 2006 5:09 am

How many glyphs does the experemental cache hold?

I think it should hold at least 70 glyphs, as this would be all upper, lower, and alpha chars in the basic latin set. Since this is most of the chars that would be called when typing text into a dialog box, or drawn on screen, I think it would increase performance to not be ousting such common glyphs from the cache, simply because the cache is too small.

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Tue Apr 11, 2006 5:28 pm

Wierd wrote:How many glyphs does the experemental cache hold?

I think it should hold at least 70 glyphs, as this would be all upper, lower, and alpha chars in the basic latin set. Since this is most of the chars that would be called when typing text into a dialog box, or drawn on screen, I think it would increase performance to not be ousting such common glyphs from the cache, simply because the cache is too small.
Actually it is 256 glyphs, but it's a simple define. that's enough for menus captions and some other stuff. They are all smaller than 20x20 pixels and with some additional info (face, size, ...) it might be 500 bytes/glyph. So 256 glyphs would be less than 128 kBytes. We could easily use 1000 glyphs, I think. Maybe with a size limit (20..30?)

After browsing through the FreeType types, I think it's more than 100 bytes overhead to the pixels, so a more efficient way to store it would be nice.
That and the fact that the whole function is still slow makes me think of implementing EngTextOut (wich will be needed anyway) with a more efficient caching system.

Cecico
Posts: 5
Joined: Mon Mar 20, 2006 5:52 pm

Re: ROS performance

Post by Cecico » Tue Apr 18, 2006 4:43 pm

ThePhysicist wrote: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!
This is normal because ReactOs is not completed and it is in developpement for this moment. The worst thing to do is to cross their arms and to do anything. Let's the chance to the runner. It is very early to compare Windows XP to ReactOs actualy.

kokodin
Posts: 175
Joined: Tue Nov 29, 2005 7:19 pm

Post by kokodin » Tue Apr 18, 2006 10:50 pm

i was think about font draw performance and i think that we can use linux x(gnome/kde) elements or rewrite windows 3.11 engine :D that should be faster that actualy engine (if the reason of this speed is in this engine)

Wierd
Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Post by Wierd » Tue Apr 18, 2006 11:25 pm

It has more to do with generating glyph bitmaps needlessly, which is what this patch attempts to correct. You really should only generate the bitmap once, and then use it over and over again (cached) rather than generate the bitmap from the outline in the font file every time it is called for.

As Physicist pointed out, this simple patch improved text draw performance by 300%. That isnt something to scoff at.

There still exists the possibility to improve performance even more, by cutting freetype out of the loop if a local bitmap resource for the called glyph is allready in the posession of the win32 subsystem. This way we can avoid calling (slow) freetype code unless absolutely necessary. I would expect another large speed increase from this as well.

The renderer we have works, and the UI has little to do with the renderer. The UI expects returned bitmap data, which can be manipulated and transformed VERY VERY quickly by an accellerated video card. The real trick is in avoiding needless regeneration of bitmap resources for glyph faces, and avoiding calling the rasterizer unless absolutely necessary.

The (genuine) win3.11 UI is painfully slow at displaying bitmap data, compaired to the more modern NT OS flavor counterparts. This is because of lack of hardware accelleration features. Most of ROS's graphical display faults are caused by our using software only to do the transforms. We are not using hardware accelleration with the default VBE driver.

If you want a really objective test, you would need to either compare ROS's VBE driver against XP's "VGA MODE", or run the Nvidia driver on real HW, and compare with the same driver and card on XP.

Otherwise it is apples and oranges. Personally, I think our VBE driver is bitchin fast, all things considered.

ThePhysicist
Developer
Posts: 508
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist » Sat Apr 22, 2006 12:38 am

Wierd wrote:It has more to do with generating glyph bitmaps needlessly, which is what this patch attempts to correct. You really should only generate the bitmap once, and then use it over and over again (cached) rather than generate the bitmap from the outline in the font file every time it is called for.

As Physicist pointed out, this simple patch improved text draw performance by 300%. That isnt something to scoff at.

There still exists the possibility to improve performance even more, by cutting freetype out of the loop if a local bitmap resource for the called glyph is allready in the posession of the win32 subsystem. This way we can avoid calling (slow) freetype code unless absolutely necessary. I would expect another large speed increase from this as well.
The patch will cause ROS to only render the glyphs once and use the cached bitmaps if already present. But other Freetype functions (FT_Get_Char_Index, FT_Get_Kerning) are still called each time. I don't know how fast they are, but it might increase speed more chaching those also. And I think the background is drawn for each character instead of drawing it for the complete string, IIRC.
Wierd wrote:If you want a really objective test, you would need to either compare ROS's VBE driver against XP's "VGA MODE", or run the Nvidia driver on real HW, and compare with the same driver and card on XP.
That's infact what I did. I ran the tests on ROS and XP in VGA mode and on XP with hw acceleration, wich shows the huge speed increase with hw acceleration.

Xor
Posts: 4
Joined: Mon Nov 07, 2005 7:38 am

Post by Xor » Sat Apr 22, 2006 2:49 am

good work on the glyph caching. as for other performance benchmarks, is there any chance you could try comparing testbug results between xp and reactos? testbug is an assembler program that contains alot of tests, such as text drawing and memory handling etc. you can find it here:

http://www.jorgon.freeserve.co.uk/Testbug.zip

Wierd
Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Post by Wierd » Sat Apr 22, 2006 3:51 am

ThePhysicist wrote: That's infact what I did. I ran the tests on ROS and XP in VGA mode and on XP with hw acceleration, wich shows the huge speed increase with hw acceleration.
I didnt say it wasnt.. ;P

It was more for people saying "ReactOS is slow compared to XP"-- I was pointing out that XP has HW accellerated drivers, and ROS does NOT.

For being unaccellerated, I think the VBE driver is quite fast. Could be better--- sure, but still quite fast.

XP's VGA MODE might be faster, but then again, it is also 16 color mode too. "REAL VGA" mode, and not VESA mode, like our driver is... So it is still not quite a fair comparison. There is more processing involved in a higher bitdepth for software rendering.

GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord » Sat Apr 22, 2006 11:24 am

Hi werid is right about higher color deap need more cpu power and take longer time to calc and draw. But one fact have been not adding here.
VESA call to int 0x10 is slower that calling direcly to the graphic port
out/in 0x3cX, int 10 calling to video card graphic memmory then the graphic card memmory are doing all in/out to 0x3cX and some other port to the graphic card. the test is not fair.

Only way doing fair test is take reactos VBE drv to Windows XP and run it there and check the speed. Yes our VBE drv is working in Windows XP

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot], EmuandCo and 5 guests