I have window that uses double buffering for flickerless drawing, i.e., I
use the PgMem functions to draw into an offscreen buffer and then I copy
this buffer to the window using PgDrawImage.
If I move the mouse over the window, the update slows down significantly.
Why is that? Isn’t the mouse done in hardware? (I use a voodoo card). Any
way to improve that?
Thanks
Markus
On Sun, 15 Jul 2001 13:30:31 -0400, “Markus Loffler”
<loffler@ces.clemson.edu> wrote:
I have window that uses double buffering for flickerless drawing, i.e., I
use the PgMem functions to draw into an offscreen buffer and then I copy
this buffer to the window using PgDrawImage.If I move the mouse over the window, the update slows down significantly.
Why is that? Isn’t the mouse done in hardware? (I use a voodoo card). Any
way to improve that?Mouse moving is quite a time consuming process because it
involves continuous generation/propagation of events with mouse
coordinates. As a result the cursor shape may change for example, and
even the eventual ignoring of those events requires some work…
(Start some static applications on a not so fast machine, and watch
the processor usage indicator while quickly moving the mouse over the
windows).
Playing with priorities, “masking” the window by a region that
consumes all events, or disabling the cursor are unevaluated ideas
that come to mind first.
Are the shared memory and the video memory blit methods
described by John Ferr in his “Who gives a blit” article applicable in
your case? With both the stright memory and shared memory blit methods
I’ve noticed a 10% slowdown caused by mouse movements, but the second
method is ca. 8 times faster on my computer. I can’t say much about
the third method (which should be the fastest), because my video card
does not have much memory on it…
ako
Thanks
Markus
Thanks Andrez,
I use shared memory for blitting; however, I haven’t looked at the article -
I’ll do so.
I know that the mouse generates lots of events, however if I have a popup
menu that is on top of the PgRaw widget, and the mouse moves on top of the
popup menu, there is no slowdown.
Also, I don’t remember this problem with 6.0.
Actually, there is a setting in the graphics setup “disable hardware
cursor”, but it is not selected.
Anybody knows about that setting? Maybe the graphics driver does not support
the hardware cursor.
Thanks
Markus
“Andrzej Kocon” <ako@box43.gnet.pl> wrote in message
news:3b53d71e.1376874@inn.qnx.com…
On Sun, 15 Jul 2001 13:30:31 -0400, “Markus Loffler”
loffler@ces.clemson.edu> > wrote:I have window that uses double buffering for flickerless drawing, i.e., I
use the PgMem functions to draw into an offscreen buffer and then I copy
this buffer to the window using PgDrawImage.If I move the mouse over the window, the update slows down significantly.
Why is that? Isn’t the mouse done in hardware? (I use a voodoo card). Any
way to improve that?Mouse moving is quite a time consuming process because it
involves continuous generation/propagation of events with mouse
coordinates. As a result the cursor shape may change for example, and
even the eventual ignoring of those events requires some work…
(Start some static applications on a not so fast machine, and watch
the processor usage indicator while quickly moving the mouse over the
windows).Playing with priorities, “masking” the window by a region that
consumes all events, or disabling the cursor are unevaluated ideas
that come to mind first.Are the shared memory and the video memory blit methods
described by John Ferr in his “Who gives a blit” article applicable in
your case? With both the stright memory and shared memory blit methods
I’ve noticed a 10% slowdown caused by mouse movements, but the second
method is ca. 8 times faster on my computer. I can’t say much about
the third method (which should be the fastest), because my video card
does not have much memory on it…ako
Thanks
Markus
\
Andrzej,
thanks, your advice was gold. I already used shared memory, but I didn’t
know I have to use PgDrawImagemx…
Works much better now
Markus
“Andrzej Kocon” <ako@box43.gnet.pl> wrote in message
news:3b53d71e.1376874@inn.qnx.com…
On Sun, 15 Jul 2001 13:30:31 -0400, “Markus Loffler”
loffler@ces.clemson.edu> > wrote:I have window that uses double buffering for flickerless drawing, i.e., I
use the PgMem functions to draw into an offscreen buffer and then I copy
this buffer to the window using PgDrawImage.If I move the mouse over the window, the update slows down significantly.
Why is that? Isn’t the mouse done in hardware? (I use a voodoo card). Any
way to improve that?Mouse moving is quite a time consuming process because it
involves continuous generation/propagation of events with mouse
coordinates. As a result the cursor shape may change for example, and
even the eventual ignoring of those events requires some work…
(Start some static applications on a not so fast machine, and watch
the processor usage indicator while quickly moving the mouse over the
windows).Playing with priorities, “masking” the window by a region that
consumes all events, or disabling the cursor are unevaluated ideas
that come to mind first.Are the shared memory and the video memory blit methods
described by John Ferr in his “Who gives a blit” article applicable in
your case? With both the stright memory and shared memory blit methods
I’ve noticed a 10% slowdown caused by mouse movements, but the second
method is ca. 8 times faster on my computer. I can’t say much about
the third method (which should be the fastest), because my video card
does not have much memory on it…ako
Thanks
Markus
\
Using shared memory doesn’t work with Phindows. Any way to make it working?
Any way to determine if somebody uses Phindows to decide to use PgDrawImage
instead of PgDrawImagemx?
Thanks
Markus
“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9j5431$e6v$1@inn.qnx.com…
Andrzej,
thanks, your advice was gold. I already used shared memory, but I didn’t
know I have to use PgDrawImagemx…
Works much better now
Markus“Andrzej Kocon” <> ako@box43.gnet.pl> > wrote in message
news:> 3b53d71e.1376874@inn.qnx.com> …
On Sun, 15 Jul 2001 13:30:31 -0400, “Markus Loffler”
loffler@ces.clemson.edu> > wrote:I have window that uses double buffering for flickerless drawing, i.e.,
I
use the PgMem functions to draw into an offscreen buffer and then I
copy
this buffer to the window using PgDrawImage.If I move the mouse over the window, the update slows down
significantly.
Why is that? Isn’t the mouse done in hardware? (I use a voodoo card).
Any
way to improve that?Mouse moving is quite a time consuming process because it
involves continuous generation/propagation of events with mouse
coordinates. As a result the cursor shape may change for example, and
even the eventual ignoring of those events requires some work…
(Start some static applications on a not so fast machine, and watch
the processor usage indicator while quickly moving the mouse over the
windows).Playing with priorities, “masking” the window by a region that
consumes all events, or disabling the cursor are unevaluated ideas
that come to mind first.Are the shared memory and the video memory blit methods
described by John Ferr in his “Who gives a blit” article applicable in
your case? With both the stright memory and shared memory blit methods
I’ve noticed a 10% slowdown caused by mouse movements, but the second
method is ca. 8 times faster on my computer. I can’t say much about
the third method (which should be the fastest), because my video card
does not have much memory on it…ako
Thanks
Markus
\
Markus Loffler <loffler@ces.clemson.edu> wrote:
Using shared memory doesn’t work with Phindows. Any way to make it working?
Nope. Shared memory only works on the same node.
Any way to determine if somebody uses Phindows to decide to use PgDrawImage
instead of PgDrawImagemx?
Take a look at PtQuerySystemInfo(). It returns a PhSysInfo_t
structure full of various information, and one of the things you
can descern is if the display is remote (such as via Phindows).
Look for the Ph_GCAP_PHINDOWS bit set in the gfx.possibilities
substructure within the PhSysInfo_t.
Norbert Black
QSSL Training Services
Thanks Norbert.
Would I call PtQuerySystemInfo(0 every refresh of my window or is that too
much overhead?
What about ditto. How does it work, do I get the system info for the local
PC or the ditto session. How can I determine if a session is dittoed?
Markus
“Norbert Black” <nblack@qnx.com> wrote in message
news:9j6qk8$3hp$1@nntp.qnx.com…
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Using shared memory doesn’t work with Phindows. Any way to make it
working?Nope. Shared memory only works on the same node.
Any way to determine if somebody uses Phindows to decide to use
PgDrawImage
instead of PgDrawImagemx?Take a look at PtQuerySystemInfo(). It returns a PhSysInfo_t
structure full of various information, and one of the things you
can descern is if the display is remote (such as via Phindows).
Look for the Ph_GCAP_PHINDOWS bit set in the gfx.possibilities
substructure within the PhSysInfo_t.
Norbert Black
QSSL Training Services
Markus Loffler <loffler@ces.clemson.edu> wrote:
Thanks Norbert.
Would I call PtQuerySystemInfo(0 every refresh of my window or is that too
much overhead?
Information is cached, so you’re not doing to badly. Are you
really likely to have someone join your session at any point,
though? If not, it’s probably fine to do the call when you
launch the window, and set a global variable appropriately.
What about ditto.
For Photon dittoing, via phrelay, just like Phindows.
How does it work, do I get the system info for the local
PC or the ditto session. How can I determine if a session is
dittoed?
Have a look at the PhSysInfo_t structure in the docs - there are
bits that will tell you if any of the graphics regions displaying
your session are attached to remote servers.
Norbert Black
QSSL Training Services
I tried it out and it works fine. Thanks for the advice!
Information is cached, so you’re not doing to badly. Are you
really likely to have someone join your session at any point,
though? If not, it’s probably fine to do the call when you
Not someone, myself 
Yes sure, if someone in my team gives me a call that they have problems, I’m
too lazy to run from 3rd floor to 2nd floor
Markus
launch the window, and set a global variable appropriately.
What about ditto.
For Photon dittoing, via phrelay, just like Phindows.
How does it work, do I get the system info for the local
PC or the ditto session. How can I determine if a session is
dittoed?Have a look at the PhSysInfo_t structure in the docs - there are
bits that will tell you if any of the graphics regions displaying
your session are attached to remote servers.
Norbert Black
QSSL Training Services
Hi Markus
A guardian angel having pointed out the need (quite gently,
really 
), allow me to correct/amplify my reply…
Norbert Black <nblack@qnx.com> wrote:
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Using shared memory doesn’t work with Phindows. Any way to
make it working?Nope. Shared memory only works on the same node.
Serves me right for not looking more closely at the start of this
thread - I took your question out of context, and replied
respecting the use of shared memory by processes on two separate
nodes, which can’t be done.
You can make images that are stored in shared memory on a QNX
node show up on a remote Phindows link. The key is to calculate
a CRC tag for the image with PtCRC(), and then use that value as
the tag paramater to PgDrawImagemx() so that phrelay will
transmit them over the link between itself and Phindows.
Here’s the relevant bit of the docs:
int PgDrawImagemx( void const *ptr,
int type,
PhPoint_t const *pos,
PhDim_t const *size,
int bpl,
long tag );
[snip]
The tag argument is used for data caching by programs such as
phrelay (see the QNX 6 Utilities Reference). To calculate the
tag, use PtCRC(). This argument is ignored if you set it to 0.
So, Markus, if your code routinely fills in the tag, you
shouldn’t have to test for remote display via PtQuerySystemInfo()
each time you want to do a PgDrawImage*() call.
Norbert Black
QSSL Training Services
Thanks Norbert.
However, to achieve a maximum frame rate, I’m not sure what the overhead of
calculating a tag is. I guess it’s some kind of checksum, so it needs to
loop over the whole image buffer.
Of course, the advantage is that phditto is faster when the image does not
change and the cached image can be used.
Markus
“Norbert Black” <nblack@qnx.com> wrote in message
news:9jhd3d$jtr$1@nntp.qnx.com…
Hi Markus
A guardian angel having pointed out the need (quite gently,
really >Norbert Black <> nblack@qnx.com> > wrote:
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Using shared memory doesn’t work with Phindows. Any way to
make it working?Nope. Shared memory only works on the same node.
Serves me right for not looking more closely at the start of this
thread - I took your question out of context, and replied
respecting the use of shared memory by processes on two separate
nodes, which can’t be done.You can make images that are stored in shared memory on a QNX
node show up on a remote Phindows link. The key is to calculate
a CRC tag for the image with PtCRC(), and then use that value as
the tag paramater to PgDrawImagemx() so that phrelay will
transmit them over the link between itself and Phindows.Here’s the relevant bit of the docs:
int PgDrawImagemx( void const *ptr,
int type,
PhPoint_t const *pos,
PhDim_t const *size,
int bpl,
long tag );
[snip]
The tag argument is used for data caching by programs such as
phrelay (see the QNX 6 Utilities Reference). To calculate the
tag, use PtCRC(). This argument is ignored if you set it to 0.So, Markus, if your code routinely fills in the tag, you
shouldn’t have to test for remote display via PtQuerySystemInfo()
each time you want to do a PgDrawImage*() call.
Norbert Black
QSSL Training Services
Markus Loffler <loffler@ces.clemson.edu> wrote:
Thanks Norbert.
However, to achieve a maximum frame rate, I’m not sure what the overhead of
calculating a tag is. I guess it’s some kind of checksum
Yes, it’s a checksum.
so it needs to
loop over the whole image buffer.
Whole image buffer? Sorry, I may be missing some context here?
The tag is associated with a particular image, not with the
draw buffer.
Of course, the advantage is that phditto is faster when the image does not
change and the cached image can be used.
Yes, anything that’s repetative and tagged will be faster, over a
period of time.
Norbert Black
QSSL Training Services
“Norbert Black” <nblack@qnx.com> wrote in message
news:9jk233$9df$1@nntp.qnx.com…
Markus Loffler <> loffler@ces.clemson.edu> > wrote:
Thanks Norbert.
However, to achieve a maximum frame rate, I’m not sure what the overhead
of
calculating a tag is. I guess it’s some kind of checksumYes, it’s a checksum.
so it needs to
loop over the whole image buffer.Whole image buffer? Sorry, I may be missing some context here?
The tag is associated with a particular image, not with the
draw buffer.
To calculate a checksum, don’t you need to loop through all the data bytes
and add them up somehow?
Or is the tag just a sequential number of some sort?
Of course, the advantage is that phditto is faster when the image does
not
change and the cached image can be used.Yes, anything that’s repetative and tagged will be faster, over a
period of time.
Norbert Black
QSSL Training Services