When is Double Buffering in the GUI supported?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

When is Double Buffering in the GUI supported?

Post by ma-games.de » Sun Dec 19, 2004 3:50 pm

When are you guys going to support dupple buffering in the gui? Is this a pretty hard thing to do? Personally for me, this is more important than the networking feature.

w3seek
Developer
Posts: 144
Joined: Tue Nov 23, 2004 12:12 am

Post by w3seek » Sun Dec 19, 2004 4:01 pm

Double buffering has been supported for ages already...

ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de » Sun Dec 19, 2004 4:44 pm

What I mean is that the control stuff on windows like labels, buttons and so on is paintet not at once. I meant this with double buffering.

Delfi
Posts: 76
Joined: Sat Nov 27, 2004 8:45 pm

Post by Delfi » Sun Dec 19, 2004 5:06 pm

w3seek wrote:Double buffering has been supported for ages already...


*boots qemu reactos 0.2.4*

not that i would believe in that, i can see how both
layers of shadowed text on desktop are drawn slowly.

nothin2g
Posts: 39
Joined: Fri Nov 26, 2004 6:42 pm
Location: Zeil in Bayern

Post by nothin2g » Sun Dec 19, 2004 8:56 pm

double buffering would be nice, the gui would look more stable because of this ;)

w3seek
Developer
Posts: 144
Joined: Tue Nov 23, 2004 12:12 am

Post by w3seek » Mon Dec 20, 2004 1:42 am

1. windows doesn't use double buffering everywhere, ReactOS/WINE does/should only use them where windows uses them
2. Double-buffering does not increase stability nor "looks" more stable at all, but it for sure slows down the system even more
3. An example where ROS uses double buffering - where it shouldnt - is the caption bar - windows doesn't and we propably revert this - the reason ReactOS double-buffers it was that back about a year when there was barely a GUI everything was so slow that it looked ugly when the font and everything was rendered so slowly ;)

Harteex
Posts: 224
Joined: Fri Nov 26, 2004 9:21 pm
Location: Sweden
Contact:

Post by Harteex » Mon Dec 20, 2004 2:43 am

Actually I agree with nothing2g, it sure does look more stable with double buffering :P

nothin2g
Posts: 39
Joined: Fri Nov 26, 2004 6:42 pm
Location: Zeil in Bayern

Post by nothin2g » Tue Dec 21, 2004 10:02 am

does winnt does more doublebuffering than win9x?
at least i imagine it
Wir sind die Borg. Widerstand ist Spannung durch Stromstärke.
www.wakka.de

ma-games.de
Posts: 197
Joined: Sat Nov 27, 2004 12:49 pm
Location: Lichtenfels in Bayern (Germany)
Contact:

Post by ma-games.de » Tue Dec 21, 2004 10:37 am

What ever the reason for this is. The surface needs to be improved. As I already said: For me, this is more important than the networking stuff.

SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Post by SomeGuy » Tue Dec 21, 2004 4:44 pm

Right now most of ReactOS is being designed to just get things working, so there is a lot of unoptimal code. Just for laughs I loaded up Windows 95 in QEMU and its start menu, drop down menus, and dialogs appear almost instantly whereas with ReactOS it takes several seconds to draw out.

There are various reasons for the slow speed. The video driver doesn't support acceleration, ReactOS uses antialiased fonts, and there is a problem with the USER code that was supposed to be rewritten but has been delayed.

Linuxhippy
Posts: 39
Joined: Fri Dec 03, 2004 2:24 pm

Hmm...

Post by Linuxhippy » Wed Dec 22, 2004 1:28 pm

What ever the reason for this is. The surface needs to be improved. As I already said: For me, this is more important than the networking stuff.
@ma-games.de:
It would be great if you could help the reactos team with enhancing win32k-code or donate to developers working on this!
This would really help...

lg

Post Reply

Who is online

Users browsing this forum: No registered users and 13 guests