timing to prevent window blinking

[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

[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

[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

[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)

[matthias]

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?

[Da_Maestro]

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).

[carbonBased]

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.

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.

[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)

[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...

[Da_Maestro]

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

[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

[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

Code: Select all

rep movsd

The CPU will actually start moving whole cache lines instead of just dwords (are the cache lines 64 bytes or 32?)

[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

[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)

[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