Linear frame buffering of video?

All development related issues welcome

Moderator: Moderator Team

LOst
Posts: 27
Joined: Sat Feb 12, 2005 9:33 pm

Linear frame buffering of video?

Post by LOst »

The Windows 95/98 virtual flat frame buffer device (Vflatd.vxd). Vflatd.vxd provides a frame buffer that can be up to 1 MB in size. Windows 3.1 video drivers are limited to a 64K frame buffer that affects your available system resources.
This is something I have always wondered about. How can Windows be so fast with graphics in VGA modes that are planear?
This vflatd virtual device is interesting.

I have some questions for your developers:

-How can Windows do linear buffering so fast even when using a non-linear graphics mode? It doesn't even use dubble buffering because that's low, right?

-Why doesn't ReactOS draw things as fast as Windows when it isn't using accelerated hardware?

-Is there something I can do to make ReactOS faster?

AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

ros gdi is slow because of the somewhat poorly designed (don't flame me guys, this is the truth) graphics subsystem. Ask any ros dev. The problem is mainly due to graphics drivers, or more specifically, the lack of them. It is also due to the poor implementation of the IntEng*** functions (which could use a great deal of assembly optimization; writing graphics functions in scalar c is pure foolishness).
The recent SVN builds are much faster than version 0.2.5 though; perhaps you've been using that?
Anyway, if you want to make ros faster you are quite welcome :D. Beware, though, the graphics subsystem is more complicated than might seem at first.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.

blight
Developer
Posts: 35
Joined: Tue Nov 30, 2004 10:34 pm
Location: away

Post by blight »

.-.
Last edited by blight on Wed Feb 23, 2005 1:47 pm, edited 1 time in total.

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

hmm..

Post by Linuxhippy »

ros gdi is slow because of the somewhat poorly designed
Where have you that picked up from?? ROS's GDI is quite fast (compared to other things of it), one of the bigger problems (according to w3seek) is the W32K part in userspace.
fool! writing things in C is portable, much more easy to maintain and understand.
it simply doesnt make any sense to put effort into such things too early because you might end up having to rewrite half of it only because a bug you find later, whatever, ...
Well, in the current development state this is more than just true!
But if it comes down to 1.0 or somewhere in this are I don't see any reasons why some research in this area would not make sence. If an asm-version optimized for i686/mmx is 50% faster I would take it into with some fallbacks to the default C version.

However, ROS is great and I am waiting to 0.3 - it sure will be a great release!

lg Clemens

AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

fool! writing things in C is portable, much more easy to maintain and understand.
Thank you for answering me so very understandingly and patiently. :shock:

I can't accept that bloated code is justified just because it's easier to write. ros gdi doesn't even make use of technologies such as MMX (which have become de facto in windows). Sometime in the future, ros will need to be ported to other architectures such as 64-bit machines. You're claiming that C is better just because it can be compiled with very little change on both platforms? I have news for you: Graphics is low-level stuff. It deals with input/output and interrupts and video cards. The graphics subsystem will need to be rewritten anyway (or seriously patched, which makes little difference).

And it's not just about the graphics subsystem. Even if I take your word and believe that ros gdi is fast (NOT!) there is more to it than that. Ever tried to write an mpeg video codec in C? Ended up with more of a slideshow, no? Or even if it DID manage to work on a 3GHz P4, it was probably running at 99% of CPU.
it simply doesnt make any sense to put effort into such things too early because you might end up having to rewrite half of it only because a bug you find later, whatever, ...
Ok, maybe not now, but you have to admit that optimized functions are going to be a necessity in the very near future (just take a look at the amount of user complaints that ros is slow).

You're nice people. You just don't understand anything about computer graphics.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.

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

Well...

Post by Linuxhippy »

Well, if noone understand a bit about computer graphics, why don't you go and write our imaging routines in asm, they could be switched on with compile-time switches.
And it's not just about the graphics subsystem. Even if I take your word and believe that ros gdi is fast (NOT!) there is more to it than that. Ever tried to write an mpeg video codec in C? Ended up with more of a slideshow, no? Or even if it DID manage to work on a 3GHz P4, it was probably running at 99% of CPU.
I know an MPEG4 (4!!) decoder written in JAVA - yes JAVA. It plays MPEG4 in an 1,2Ghz machine withought problems - witten in C it maybe would be about 25% faster.

You may not forget that the problem with asm is that it is very hard to get good performance on all processors (especially in the x86 world this is an ugly issue - you just have this crappy x86 interface and dont know how the internal risc machine works with your code).
With C you just recompile with new switches and everything works like expected.

As I said - write one if you are not happy how its currently is.
With naming our devs more or less idiots thing wont beome better

lg Clemens

AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

Well, if noone understand a bit about computer graphics, why don't you go and write our imaging routines in asm, they could be switched on with compile-time switches.
That would be no use. The developers would only flame me for messing up the code.
The problem isn't the development of optimized routines, it's the acceptance of them. No one seems to accept that optimized routines are far better. Every time I bring up the issue, people who can't write in assembly come up with a dozen silly excuses to not write them, hence my last remark.
With naming our devs more or less idiots thing wont beome better
Ok, you're right. I regret my rash remark. But things won't get any better with devs going their own way and not taking others into account either.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.

GvG
Posts: 499
Joined: Mon Nov 22, 2004 10:50 pm
Location: The Netherlands

Post by GvG »

AcetoliNe wrote:The problem isn't the development of optimized routines, it's the acceptance of them. No one seems to accept that optimized routines are far better. Every time I bring up the issue, people who can't write in assembly come up with a dozen silly excuses to not write them
I for one am not against optimized assembly routines (look at reactos/subsys/win32k/dib/dib16bpp.c, function DIB_16BPP_HLine()), but I do want to see a clear and measurable improvement. If you create e.g. a new test for reactos/apps/utils/rosperf which demonstrates that your asm implementation is far better than the C implementation I'll be most happy to commit your changes.
IMO the biggest trap with optimizing is that often most of the time is NOT spent where you think it is spent. Profiling (we have a nice /PROFILE boot switch) helps to determine what you actually want to optimize. Just replacing random pieces of C code with asm is not what you (or rather, I <g>) want to do.

blight
Developer
Posts: 35
Joined: Tue Nov 30, 2004 10:34 pm
Location: away

Post by blight »

---
Last edited by blight on Wed Feb 23, 2005 1:48 pm, edited 1 time in total.

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

Post by w3seek »

I prefer keeping and optimizing C code much over replacing things with asm

AcetoliNe
Posts: 115
Joined: Wed Jan 05, 2005 10:53 pm
Location: a thousand miles from Hinterland
Contact:

Post by AcetoliNe »

IMO the biggest trap with optimizing is that often most of the time is NOT spent where you think it is spent. Profiling (we have a nice /PROFILE boot switch) helps to determine what you actually want to optimize. Just replacing random pieces of C code with asm is not what you (or rather, I <g>) want to do.
You're quite right. This is, in fact, one of the most troubling problems with optimiziation; most of the time you're just optimizing the wrong code!
And I agree, replacing random pieces of C code with asm is not very attractive either.
I really want optimized code. I've been wanting to write asm replacements for functions for a long time now, but I have very little spare time. I've brought the issue up so much that I'll have to write it eventually, even if only out of not losing face ;).
I hope you arent referring to me
Not necessarily. I just mean people who don't realize the significance of assembly optimization.
Somehow Lots of developers wrongly believe that good C code can replace asm code. Nothing could be further from the truth (especially with a general purpose compiler like MinGW). In my experience (i'm not guessing; this is experience) even the poorest asm code can outrun the best-written C code easily.
Another thing which you might not be aware of is that in windows in kernel mode (and probably any other modern OS) you cannot simply use the FPU/MMX/SSE opcodes - you have to save the FPU/MMX/SSE state before using it and restore it afterwards which could produce so much overhead that the MMX optimizations become useless.
AFAIK, that's only true with MMX (because of conflicts with the FPU). I don't think that's needed with SSE; I believe the processor saves the SSE state automatically.
caveman LIKES chocolate.
we shall reinvent the wheel until it turns properly.

blight
Developer
Posts: 35
Joined: Tue Nov 30, 2004 10:34 pm
Location: away

Post by blight »

-.-
Last edited by blight on Wed Feb 23, 2005 1:47 pm, edited 1 time in total.

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

Post by w3seek »

blight: back off and please watch your language, you're pissing people off. These are legit questions and if you don't feel like answering then please don't do.

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

Post by Wierd »

.........wow.........

(Cant help but wonder if the pro-ASM crowd would rather I learn font opcode instructions, and machine code my font... rather than build it with a high level tool, because of potential performance issues......................... If so, they cah take a hike, because it is hard enough as it is.)


Personally, I hold this opinion:

ROS is in diapers still. It cant even shake its rattle with any real reliability! Hell-- It barely even HOLDS the rattle!

ASM routines are harder to debug for problems. When the graphics subsystem is more mature in terms of 'proper' operational program flow and implemented API, **THEN** it will be a ready candidate for ASM optimisation, but not before. I personally feel for anyone who would have to dig through an "Optimized" routine in ASM, to try and figure out what exactly is going on should some other function that needs implementing, for some reason or other, requires something to be changed in order to work.

Dont count chickens before they hatch---

Or in this case, complain that the chickens are too small to fry, when they are fresh from the shells!

Write C code now, and pin down the implementation first--- *THEN* build optimised routines.

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

Post by GreatLord »

reactos vbe driver does map hole graphice card memmory direcly to gdi.
when reactos write a dot it write direcly to the graphice card memory. or block of pxiel it write direcly to the graphice card.

the vga drv in reactos write one dot each time. it can not wirte all pixel same time. it need call setpixel hole time and switch memmory bank.
when it need.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot] and 1 guest