Page 1 of 2
timing to prevent window blinking
Posted: Sat Mar 04, 2006 12:00 am
by earlz
Well really i am wondering what is a good timing combo for cls'ing(the screen) and drawing windows
currently its 60hz (every 60ms)
but when i added in cls it started to flicker
so what should it be?
every way ive tried it it flickers
Re: timing to prevent window blinking
Posted: Sat Mar 04, 2006 12:00 am
by carbonBased
60hz != 60ms.
You should wait for the vertical retrace before doing any screen updates. You should also copy dwords at all times, whenever possible.
--Jeff
Re: timing to prevent window blinking
Posted: Sat Mar 04, 2006 12:00 am
by earlz
hmmm yes vertical retrace
but i was afraid my drawing will take longer than vertical retrace
and the dword thing
yea thats a big optimization tip speed it up 4 times
Re: timing to prevent window blinking
Posted: Sun Mar 05, 2006 12:00 am
by JAAman
you could also use on-board buffering -- though that won't work on 'standard' VGA (in graphics mode -- but then in text mode it isn't a big deal anyway), but most cards supporting any more advanced modes should have enough memory to handle it -- though you will need vbe3, v86-vbe, or a proper driver (only practical for older, or intel controllers)
Re: timing to prevent window blinking
Posted: Sun Mar 05, 2006 12:00 am
by matthias
hckr83 wrote:
and the dword thing
yea thats a big optimization tip speed it up 4 times
I might be wrong but it isn't it a speed up with the power of 4 and not times for?
Re: timing to prevent window blinking
Posted: Mon Mar 06, 2006 12:00 am
by Da_Maestro
matthias wrote:hckr83 wrote:
and the dword thing
yea thats a big optimization tip speed it up 4 times
I might be wrong but it isn't it a speed up with the power of 4 and not times for?
No. It's a x4 increase in speed. There is no way of increasing the speed of a copy operation by an exponential amount because every copy operation is of order O(n).
Re: timing to prevent window blinking
Posted: Tue Mar 07, 2006 12:00 am
by carbonBased
hckr83 wrote:hmmm yes vertical retrace
but i was afraid my drawing will take longer than vertical retrace
You should be able to. If you're always composing your graphics offscreen and merely blitting a buffer to the screen, you should be able to perform this within a refresh and eliminate flicker.
hckr83 wrote:
and the dword thing
yea thats a big optimization tip speed it up 4 times
It's a performance must -- not just for graphics, either. Also note that they need to be dword aligned dwords, as well, or else the pipeline will break up the writes into more then one aligned write.
Re: timing to prevent window blinking
Posted: Wed Mar 08, 2006 12:00 am
by JAAman
no, only if it crosses a 64bit boundry (thats a qword) will it require more than one read (at least on P5+ -- you are correct for 386/486)
Re: timing to prevent window blinking
Posted: Wed Mar 08, 2006 12:00 am
by carbonBased
You're saying that the following code can compile and run without any alignment issues?
long longValue = 10;
char *byteAligned = 0x00000001;
*((long*)byteAligned) = longValue;
That doesn't sound right to me...
Re: timing to prevent window blinking
Posted: Wed Mar 08, 2006 12:00 am
by Da_Maestro
carbonBased wrote:You're saying that the following code can compile and run without any alignment issues?
long longValue = 10;
char *byteAligned = 0x00000001;
*((long*)byteAligned) = longValue;
That doesn't sound right to me...
The code will run, it will just run twice as slow
Re: timing to prevent window blinking
Posted: Thu Mar 09, 2006 12:00 am
by JAAman
no it wont -- the CPU (beginning with the P5) fetches 64bits at a time (not 32) regardless of the size of data -- therefore, there will be no penalty if the fetch doesn't cross a 64bit boundary
Re: timing to prevent window blinking
Posted: Thu Mar 09, 2006 12:00 am
by Da_Maestro
uh-huh...
But what if you are running on an AMD?
Or a Cyrix?
Or an older intel?
What if you want to port your code to SPARC? It wont run *at all* if values are not aligned.
What if you are reading double precision floating point rather than long integer? That's a 64-bit number and it will improve performance vastly if numbers are aligned.
and the dword thing
yea thats a big optimization tip speed it up 4 times
Well if we are talking about the later processors, the speed increase is actually 64 times over. When you use a string copy operation such as
The CPU will actually start moving whole cache lines instead of just dwords (are the cache lines 64 bytes or 32?)
Re: timing to prevent window blinking
Posted: Fri Mar 10, 2006 12:00 am
by JAAman
What if you are reading double precision floating point rather than long integer? That's a 64-bit number and it will improve performance vastly if numbers are aligned.
uh -- i think you missed my point -- you said that dword transfers should be dword aligned -- i said, i should be qword aligned -- not that it shouldn't be aligned at all -- infact, some things are
required to be aligned (even on x86)
But what if you are running on an AMD?
i believe AMD chips have also been 64bit -- at least since the Athlon (more likely later k6s, though i am less knowledged about early AMD designs)
yes, older chips (486 and earlier) should be dword aligned -- but most people (i am an exception, btw) ignore anything older than the P5 (some even northwood) because it makes OSdev much easier
Re: timing to prevent window blinking
Posted: Sun Mar 12, 2006 12:00 am
by Da_Maestro
no my point was that the code quoted before by carbonbased would infact run twice as slow (well at least the statement assigning the value to the misaligned variable)
Re: timing to prevent window blinking
Posted: Mon Mar 13, 2006 12:00 am
by JAAman
no it would not -- because as long as the data does not cross a
qword boundry (which that example code doesn't), it will be done in a single (actually 1/4 on P-IVs) bus cycle because the CPU will actually transfer a qword into the memory bus, but only latch a dword that is located from bytes 1-4, and ignore bytes 0, 5, 6, & 7
like this:
mov [0x01], eax
transfer:
Code: Select all
byte 0 1 2 3 4 5 6 7
data transfer x AL AH EAX x x x
all will be transfered in a single transaction, not 2
x is values ignored by the memory subsystem, and AL = AL, AH = AH, EAX= high word of EAX register