[haiku] Re: Accelerated versus double buffered.

  • From: Gerald Zajac <zajacg@xxxxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 05 Mar 2009 18:21:19 -0500

Stephan Aßmus wrote:
Hm. See <http://dev.haiku-os.org/ticket/2769#comment:12>. Thing is, I am using this patch myself since quite a while (Core2Duo, nVidia 7300 PCIe). And now I am wondering if it should be commited to trunk. It's just that I don't really have an idea about the effects on slower computers. Can people who run Haiku natively on slower hardware, but *with* native graphics driver support, apply this patch and tell me how Haiku feels with that?

Logic dictates, somehow, that the effect of this patch should benefit slow computers as much as it does fast computers. However, it effectively removes all graphics driver acceleration. But why does the graphics feel smoother and there is less strain on the CPU than with accelerated graphics? Is the software cursor really that bad when using accelerated graphics otherwise? Anyways, please tell me your findings, if you get the chance to test this on slower computers with accelerated native graphics. Thanks a lot!

I'm unable to apply this patch since I currently do not have a usable build system; however, I did compare the performance of an S3 Savage4 video card with 16 MB of memory on a computer with an 866 Mhz Pentium III processor and 256 MB of RAM. I used r28289 which did not have double buffering, and r29382. Unless this patch greatly speeds up the double buffering, the video performed noticeably better under r28289 without double buffering.

Using the S3 driver, the GLTeapot demo draws at a frame rate in the mid 40's under both Haiku rev's if no other screen activity is occurring. However, if I continuously move the Terminal window around the screen, there is a very noticeable difference in the GLTeapot frame rate. Under r28289, the frame rate is in the low 20's, and under r29382, it is around 5 FPS.

Furthermore, another test was performed by displaying both the Screen and Background preference dialogs simultaneously, and continuously moving the Terminal window over them. Under r28289, there is no noticeable delay in redrawing these dialog boxes; however, under r29382, the redrawing of the dialogs is noticeably slower.

I hope that this info is of some value. If I can setup a usable build system, I will try your patch.

Best regards,
Gerald



Other related posts: