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]>
