Hi
I am sorry to make troubles to you with my carzy outlook software. Is this
message ok?
About my question. Look at my code attentivily. That piece of shit has to
run not more not less than 10 sec. It should nod deppend on the target. What
is strange that function clock returned wrong result depending on GGI mode.
Best Regard. Dmitry.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 04, 1999 20:35
To: [EMAIL PROTECTED]
Subject: Re: ggiFlush
Hi !
Ummh ... :
[Charset windows-1251 unsupported, skipping...]
Could you try to persuade your OutLook to send a somewhat standard format ?
It sets the IMHO totally bogus headers:
Content-type: text/plain; charset="windows-1251"
Content-transfer-encoding: 7bit
What makes it a pain for me to reply to your mail. I had to copy it to a
second terminal and repaste from there ...
> I've just signed up to the mail list. I am thinking to use GGI lib to my
> next project.
Fine, welcome on board.
> I found some strange in sync mode or in async with flush calling(Linux
> Intel). I wrote some function Run using clock function to measure func
> speed. Function "func" calls CrossBlit with Flush(async mode)or without
> Flush(sync mode).
O.K.
> Under X target I was staying inside of RUN 20-30 sec. Why?
> Under Svga target everything is Ok. I've got 10 sec.
You are probably running on a relatively large mode - right ? Or maybe you
were running remotely (i.e. with the X display not set to the local machine
or the X server not being XShm-capable) ?
It is normal, that X is slower than directly drawing to video memory.
On directly-mapped targets like SVGAlib and KGIcon, ggiFlush is a NoOp,
while on inherently asynchronous targets like X, it might have to copy over
the whole frame from a background buffer.
If you do not update the whole framebuffer, but only part of it,
ggiFlushRegion might help.
Please note, that LibGGI is known to have a very fast X target
implementation.
We have beaten native implementations in some games serveral times by just
making a LibGGI port.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
