Hi,
I am blitting one offscreen context to an other (both 800x600x32) using PgContextBlit and PgSetChroma (color keying). Even though it works, I wonder about the fairly large amount of time that this operation consumes. It takes about 300 ms and the mouse pointer can’t be moved during this operation. Blitting w/o chroma keying is much faster (about 10ms).
I am evaluating QNX 6.2 and tried this with devg-rage.so and devg-ati_rage128.so.
The doc’s say chroma-keyed blitting is accelerated, but the capability flags (PgGetVideoModeInfo) say it’s not.
Since I use source color keying, I expected it as fast an normal blitting.
So the question is:
Is chroma-keying really accelerated for the rage and rage128 cards?
And by the way:
Is it possible the set a mask for the chroma color?
TIA
Peter Stoeckigt
STN Atlas Marine Electronics GmbH
Dipl.-Ing. Peter Stoeckigt
Department MST21
Bremen, Germany
Phone: +49 (421) 1784-1190
Fax: +49 421 457 2026
http://www.sam-electronics.de
Hey Peter
It appears that the card is falling back in to software mode even though it
supports this option in hardware mode. Can we get a sample application that
demonstrates this problem?
Thanks,
Rodney
“Peter Stöckigt” <stoeckigt.p@stn-atlas.de> wrote in message
news:ahj3ck$sdh$1@inn.qnx.com…
Hi,
I am blitting one offscreen context to an other (both 800x600x32) using
PgContextBlit and PgSetChroma (color keying). Even though it works, I wonder
about the fairly large amount of time that this operation consumes. It takes
about 300 ms and the mouse pointer can’t be moved during this operation.
Blitting w/o chroma keying is much faster (about 10ms).
I am evaluating QNX 6.2 and tried this with devg-rage.so and
devg-ati_rage128.so.
The doc’s say chroma-keyed blitting is accelerated, but the capability flags
(PgGetVideoModeInfo) say it’s not.
Since I use source color keying, I expected it as fast an normal blitting.
So the question is:
Is chroma-keying really accelerated for the rage and rage128 cards?
And by the way:
Is it possible the set a mask for the chroma color?
TIA
Peter Stoeckigt
STN Atlas Marine Electronics GmbH
Dipl.-Ing. Peter Stoeckigt
Department MST21
Bremen, Germany
Phone: +49 (421) 1784-1190
Fax: +49 421 457 2026
http://www.sam-electronics.de
I tried one day to write a small app. to extract this problem, but it seems that I made a mistake. It appears that the offscreen contexts that I used aren’t really offscreen rather than system memory (even though it is also offscreen). I underestimated the amount of memory needed and PdCreateOffscreenContext() obviously returns system memory if there is no more video memory available (I read somewhere in this group that this behavior is driver dependent). So this point isn’t any longer an issue. Thanks.
But what about the capability flags and the chroma mask?
I attached a small source to print the capability flags.
Thanks,
Peter
Hello Peter
The capability flags are being incorrectly reported. This is a bug and a PR
has been created to address the situation. Chroma Masking or ranged chroma
is not supported at this time.
Thanks,
Rodney
“Peter Stöckigt” <stoeckigt.p@stn-atlas.de> wrote in message
news:ajdjkn$630$1@inn.qnx.com…
I tried one day to write a small app. to extract this problem, but it seems
that I made a mistake. It appears that the offscreen contexts that I used
aren’t really offscreen rather than system memory (even though it is also
offscreen). I underestimated the amount of memory needed and
PdCreateOffscreenContext() obviously returns system memory if there is no
more video memory available (I read somewhere in this group that this
behavior is driver dependent). So this point isn’t any longer an issue.
Thanks.
But what about the capability flags and the chroma mask?
I attached a small source to print the capability flags.
Thanks,
Peter
Hello Rodney,
I tried chroma keyed blitting again with a rage128 card and the problem is back. I assume you are still interested in a sample application that demonstrates the problem (see attachment). It seems that, when using Pg_CHROMA_DRAW in ChromaOp, it’s done in software.
An other question is: Which draw context is used when I blit to the screen by setting destination to NULL? I setup chroma for the current offscreen context and then blitted to the screen, but chroma keying doesn’t work (all colors where blitted). Then I selected the default context, setup chroma, blitted to the screen and - it worked.
TIA
Peter
“Rodney Dowdall” <guisupport@qnx.com> wrote in message news:aje4h7$cqp$1@nntp.qnx.com…
Hello Peter
The capability flags are being incorrectly reported. This is a bug and a PR
has been created to address the situation. Chroma Masking or ranged chroma
is not supported at this time.
Thanks,
Rodney
“Peter Stöckigt” <> stoeckigt.p@stn-atlas.de> > wrote in message
news:ajdjkn$630$> 1@inn.qnx.com> …
I tried one day to write a small app. to extract this problem, but it seems
that I made a mistake. It appears that the offscreen contexts that I used
aren’t really offscreen rather than system memory (even though it is also
offscreen). I underestimated the amount of memory needed and
PdCreateOffscreenContext() obviously returns system memory if there is no
more video memory available (I read somewhere in this group that this
behavior is driver dependent). So this point isn’t any longer an issue.
Thanks.
But what about the capability flags and the chroma mask?
I attached a small source to print the capability flags.
Thanks,
Peter
\