What is the intended use of length on the PtTrend’s Pt_ARG_TREND_DATA
resource?
If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.
Also, there is a buglet in PhAB’s display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.
Bill Caroselli <qtps@earthlink.net> wrote:
What is the intended use of length on the PtTrend’s Pt_ARG_TREND_DATA
resource?If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.
Why? The general rule for array resources is that the length is the
number of elements in the array you’re providing. The resource is an
array of short. The length is the number of shorts in the array.
Do you think the following paragraph in the docs needs improvement:
If the widget is displaying multiple trends, the data buffer must
contain the new data for each trend: data for the first trend is
followed by data for the second trend, and so on. The application
must set len to be the total number of points being added, not the
number of points per trend.
Also, there is a buglet in PhAB’s display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.
This is just one of symptoms of the fact that neither PhAB nor the
widget library has a general way to distinguish between signed and
unsigned resources. The problem does not exist when you get a resource
using a pointer – it’s your responsibility to make sure that the
pointer has the correct type. But if get a resource without using a
pointer, it always comes back as a signed long, and if it’s a signed
char or short, it doesn’t get correctly sign extended.
I believe the PhAB folks are working on a fix for this, but I’m not sure
when it’ll actually be released.
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > Bill Caroselli <qtps@earthlink.net> wrote:
What is the intended use of length on the PtTrend’s Pt_ARG_TREND_DATA
resource?If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.
WL > Why? The general rule for array resources is that the length is the
WL > number of elements in the array you’re providing. The resource is an
WL > array of short. The length is the number of shorts in the array.
WL > Do you think the following paragraph in the docs needs improvement:
WL > If the widget is displaying multiple trends, the data buffer must
WL > contain the new data for each trend: data for the first trend is
WL > followed by data for the second trend, and so on. The application
WL > must set len to be the total number of points being added, not the
WL > number of points per trend.
I guess what threw me here was that if I added a point at a time when
there was two trends, nothing ever changed ever. I would have expected
it to update the first trend and leave the second trend alone. Instead
it just ignored the new data.
Also, there is a buglet in PhAB’s display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.
WL > This is just one of symptoms of the fact that neither PhAB nor the
WL > widget library has a general way to distinguish between signed and
WL > unsigned resources. The problem does not exist when you get a resource
WL > using a pointer – it’s your responsibility to make sure that the
WL > pointer has the correct type. But if get a resource without using a
WL > pointer, it always comes back as a signed long, and if it’s a signed
WL > char or short, it doesn’t get correctly sign extended.
WL > I believe the PhAB folks are working on a fix for this, but I’m not sure
WL > when it’ll actually be released.
I’ve never actually used a PtNumeric. I didn’t realize that it
couldn’t be used with unsigned data types. That should be spelled out
with BIG RED LETTERS!
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bkacq7$7kv$1@inn.qnx.com…
Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
WL > Bill Caroselli <> qtps@earthlink.net> > wrote:
What is the intended use of length on the PtTrend’s Pt_ARG_TREND_DATA
resource?If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.WL > Why? The general rule for array resources is that the length is the
WL > number of elements in the array you’re providing. The resource is an
WL > array of short. The length is the number of shorts in the array.WL > Do you think the following paragraph in the docs needs improvement:
WL > If the widget is displaying multiple trends, the data buffer must
WL > contain the new data for each trend: data for the first trend is
WL > followed by data for the second trend, and so on. The
application
WL > must set len to be the total number of points being added, not
the
WL > number of points per trend.I guess what threw me here was that if I added a point at a time when
there was two trends, nothing ever changed ever. I would have expected
it to update the first trend and leave the second trend alone. Instead
it just ignored the new data.
You mean you would expect that you do it repeatedly, the first trend would
move and the second one would stay in place? No, it doesn’t work that
way…
Also, there is a buglet in PhAB’s display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.WL > This is just one of symptoms of the fact that neither PhAB nor the
WL > widget library has a general way to distinguish between signed and
WL > unsigned resources. The problem does not exist when you get a
resource
WL > using a pointer – it’s your responsibility to make sure that the
WL > pointer has the correct type. But if get a resource without using a
WL > pointer, it always comes back as a signed long, and if it’s a signed
WL > char or short, it doesn’t get correctly sign extended.WL > I believe the PhAB folks are working on a fix for this, but I’m not
sure
WL > when it’ll actually be released.I’ve never actually used a PtNumeric. I didn’t realize that it
couldn’t be used with unsigned data types. That should be spelled out
with BIG RED LETTERS!
No, it’s not a PtNumeric problem – it’s the way PhAB reads the Min Value
back from PtTrend. Since it’s using the “no pointer” method,
PtGetResources() returns the value in the long “value” field of a PtArg_t.
It does that by copying the 16 bits of the short into the low 16 bits of the
long, and since it has no idea whether the short is signed or not, it always
sets the other 16 bits of the long to zero. Perhaps it would have been a
better idea to always sign-extend it – if we have to return some values
incorrectly, it’s probably better to break very big unsigned shorts than all
the negative signed shorts. But I’m not sure if changing it now would be
such a great idea…
Wojtek Lerch <wojtek_l@ottawa.com> wrote:
WL > “Bill Caroselli” <qtps@earthlink.net> wrote in message
I’ve never actually used a PtNumeric. I didn’t realize that it
couldn’t be used with unsigned data types. That should be spelled out
with BIG RED LETTERS!
WL > No, it’s not a PtNumeric problem – it’s the way PhAB reads the Min Value
WL > back from PtTrend. Since it’s using the “no pointer” method,
WL > PtGetResources() returns the value in the long “value” field of a PtArg_t.
WL > It does that by copying the 16 bits of the short into the low 16 bits of the
WL > long, and since it has no idea whether the short is signed or not, it always
WL > sets the other 16 bits of the long to zero. Perhaps it would have been a
WL > better idea to always sign-extend it – if we have to return some values
WL > incorrectly, it’s probably better to break very big unsigned shorts than all
WL > the negative signed shorts. But I’m not sure if changing it now would be
WL > such a great idea…
AAAHHHHH!!!
I understand, and agree, don’t change logic like that this late in
the game.
But the good news is this, if the application (and that includes PhAB)
knows that the value being returned is a short, then it just has to:
long value;
short s_value;
s_value = (value & 0xffff);
The sign bit from the original short should be preserved, right?
Please write that up as a bug fix. There is nothing more annoying than
to type in one number have it echo back something entirely different
than what you typed.
Bill Caroselli <qtps@earthlink.net> wrote:
Wojtek Lerch <> wojtek_l@ottawa.com> > wrote:
WL > No, it’s not a PtNumeric problem – it’s the way PhAB reads the Min Value
WL > back from PtTrend. Since it’s using the “no pointer” method,
WL > PtGetResources() returns the value in the long “value” field of a PtArg_t.
WL > It does that by copying the 16 bits of the short into the low 16 bits of the
WL > long, and since it has no idea whether the short is signed or not, it always
WL > sets the other 16 bits of the long to zero. Perhaps it would have been a
WL > better idea to always sign-extend it – if we have to return some values
WL > incorrectly, it’s probably better to break very big unsigned shorts than all
WL > the negative signed shorts. But I’m not sure if changing it now would be
WL > such a great idea…
…
But the good news is this, if the application (and that includes PhAB)
knows that the value being returned is a short, then it just has to:
The bad news is that PhAB does not know that the value is a short.
long value;
short s_value;
s_value = (value & 0xffff);
The sign bit from the original short should be preserved, right?
Yes; you don’t even need to do the &0xffff part.
But you do need to know that the value is a short.
Please write that up as a bug fix. There is nothing more annoying than
to type in one number have it echo back something entirely different
than what you typed.
It would be justified if it were different because the value you typed
in was incorrect and the widget had to adjust it. But in this case, the
widget accepted the value you typed in and it’s just the library that
reports it as a completely different valuue; and I agree it’s a bug and
it’s annoying. I probably could think of one or two things that are
even more annoying, but that doesn’t change the fact that basically I
agree with you. 
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > The bad news is that PhAB does not know that the value is a short.
Well I’m sure that PhAB should know that PtTrend’s Min Value is a short.
So I guess your saying that the dialog box doesn’t know it’s working on
a PtTrend.MinValue.
Perhaps there should be 4 dialog for editing a numeric resource.
short
long
unsigned short
unsigned long
Oh well. I’ll let it go for now and wait to 6.3.
Bill Caroselli <qtps@earthlink.net> wrote:
Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
WL > The bad news is that PhAB does not know that the value is a short.
Well I’m sure that PhAB should know that PtTrend’s Min Value is a short.
Not really. If PtGetResources() knew how to return the correct value,
PhAB wouldn’t need to care about whether the widget internally stores it
as a short or a long. The real problem is not that PhAB doesn’t know
that the value -1 comes back as 65535 for some resources or as 255 for
some others: the problem is that it doesn’t always come back as -1.
It’s not the same as the fact that if you actually try to set the
resource to 65535 or to 655359, the widget will set it to -1.
Personally, I think widgets should be allowed to do this kind of mildly
silly things if you try to set a resource to a completely silly value.
But that’s when you set it from code – PhAB should know what values are
completely silly, and shouldn’t allow you to set them. If a resource
can only accept values between 0 and 100, PhAB shouldn’t let you try to
set it to 101, or 65565, or 655359. PhAB doesn’t need to know whether a
resource like that is stored in 8 or 16 bits and whether it’s declared
signed or unsigned in the code, but PhAB needs to know the range of
valid values.
The good news is that this one is currently being worked on. And it may
even make it possible for PhAB to work around the first one. The bad
news is that the first one is tough – we’re using all the bits in the
resource definition records already, and there’s no way to add
information about the signedness to it without breaking backwards
compatibility.
OK. PtTrend isn’t quite going to do what I need.
I’m looking for some advice from one of you real low level photon gurus.
I need to present multiple trendlines, kind of like a heart beat
monitor. I need to change the color of the lines while their coming
out. (I.E. New points only. I won’t change pixels after they’ve been
displayed.) I also need to change background color as new points are
being displayed. I need to be able to draw a line across all trendlines
to mark certain events. And I need to be able to draw text, both
horizontally and vertically.
As these things are drawn I want them to scroll with the trendline.
(BTW, I will never draw text near the edges so I won’t have to worry
about clipping text as it is being drawn.)
My thoughts were this:
Use a PtTrend and overlay the text and background colors somehow.
I’m not sure that this can be done. If is can be done, I don’t think
I can make the PtTrend scroll it all.
Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
Use a PtLabel (image type) and define my own PhImage_t. (My plan
is to use 1 byte per pixel.) I can do my own graphics into this image
(I think) and I can do my own blitting of this image. But can I draw
text into my PhImage_t?
BTW, I’d like to update my image 4-10 times per second.
What is the best aproach?
Bill Caroselli wrote:
OK. PtTrend isn’t quite going to do what I need.
I’m looking for some advice from one of you real low level photon gurus.
I need to present multiple trendlines, kind of like a heart beat
monitor. I need to change the color of the lines while their coming
out. (I.E. New points only. I won’t change pixels after they’ve been
displayed.) I also need to change background color as new points are
being displayed. I need to be able to draw a line across all trendlines
to mark certain events. And I need to be able to draw text, both
horizontally and vertically.As these things are drawn I want them to scroll with the trendline.
(BTW, I will never draw text near the edges so I won’t have to worry
about clipping text as it is being drawn.)My thoughts were this:
Use a PtTrend and overlay the text and background colors somehow.
I’m not sure that this can be done. If is can be done, I don’t think
I can make the PtTrend scroll it all.Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
Yes, using PtBlit()
- Use a PtLabel (image type) and define my own PhImage_t. (My plan
is to use 1 byte per pixel.) I can do my own graphics into this image
(I think) and I can do my own blitting of this image. But can I draw
text into my PhImage_t?
You can draw text into your PhImage_t using a memory context
(PmMemCreateMC())
BTW, I’d like to update my image 4-10 times per second.
What is the best aproach?
Dave Rempel <drempel@qnx.com> wrote:
DR > Bill Caroselli wrote:
My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
DR > Yes, using PtBlit()
I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
inside of my main window.
Also on my main window I have a PtButton I’ve added for diagnostic
purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
row.
The blitting is working, BUT the draw function for my PtRaw is also
being called. Nothing should be damaging the widget.
Why is the draw function being called?
I’m using blitting because I don’t want to redraw the whole thing!
The button that I’m clicking does not over lap PtPanelGrou in any way.
Bill Caroselli <qtps@earthlink.net> wrote:
BC > Dave Rempel <drempel@qnx.com> wrote:
BC > DR > Bill Caroselli wrote:
My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > DR > Yes, using PtBlit()
BC > I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.
BC > Also on my main window I have a PtButton I’ve added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.
BC > The blitting is working, BUT the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.
BC > Why is the draw function being called?
BC > I’m using blitting because I don’t want to redraw the whole thing!
BC > The button that I’m clicking does not over lap PtPanelGrou in any way.
I did a little more research. It is the call to PtBlit that is
damaging the widget. If I comment out the PtBlit() call then my draw
function does not get called.
What am I doing wrong?
I’m still waiting to find out why PtBlit() is damaging my widget
(I.E. forcing my draw_f() function ot be called.
I have a new problem.
In my draw function I call:
PhRect_t my_rect;
PtCalcCanvas( widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
where ‘widget’ is from the draw callback, and this works. Everything I
draw is where I expect it to be.
Later in the program some external event occurs and I try to display a
new object on the PtRaw widget. I call:
PhRect_t my_rect;
PtCalcCanvas( ABW_my_widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
but the translation is off. I.E. it draws too high. Above my PtRaw
widget actually. Note: I left the clipping off just so I could see
where it was drawing.
Why is my translation wrong?
In th PgSetTranslation(), PgRELATIVE is relative to what?
Note: there is no telling what widget had focus when the additional
draw was attempted.
Bill Caroselli <qtps@earthlink.net> wrote:
BC > Bill Caroselli <qtps@earthlink.net> wrote:
BC > BC > Dave Rempel <drempel@qnx.com> wrote:
BC > BC > DR > Bill Caroselli wrote:
My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > BC > DR > Yes, using PtBlit()
BC > BC > I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > BC > inside of my main window.
BC > BC > Also on my main window I have a PtButton I’ve added for diagnostic
BC > BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > BC > row.
BC > BC > The blitting is working, BUT the draw function for my PtRaw is also
BC > BC > being called. Nothing should be damaging the widget.
BC > BC > Why is the draw function being called?
BC > BC > I’m using blitting because I don’t want to redraw the whole thing!
BC > BC > The button that I’m clicking does not over lap PtPanelGrou in any way.
BC > I did a little more research. It is the call to PtBlit that is
BC > damaging the widget. If I comment out the PtBlit() call then my draw
BC > function does not get called.
BC > What am I doing wrong?
Can someone at QSSL take a stab at this?
Bill Caroselli <qtps@earthlink.net> wrote:
BC > Dave Rempel <drempel@qnx.com> wrote:
BC > DR > Bill Caroselli wrote:
My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > DR > Yes, using PtBlit()
BC > I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.
BC > Also on my main window I have a PtButton I’ve added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.
BC > The blitting is working, BUT the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.
BC > Why is the draw function being called?
BC > I’m using blitting because I don’t want to redraw the whole thing!
BC > The button that I’m clicking does not over lap PtPanelGrou in any way.
Bill Caroselli <qtps@earthlink.net> wrote:
Can someone at QSSL take a stab at this?
PtBlit() damages the portion of the source rectangle that doesn’t
overlap with the destination rectangle. For instance, if you’re
blitting by one pixel to the right, it’ll damage a one-pixel strip along
the left adge of the rectangle.
It also will damage any portions of the destination area where the
corresponding source area is invisible (i.e. outside of the canvas; I
don’t think we handle cases where there’s another widget on top of the
one you’re blitting). For instance, if you take a huge rectangle and
blit it by one pixel to the left, it’ll damage a one-pixel strip along
the right edge of the canvas.
Bill Caroselli <> qtps@earthlink.net> > wrote:
BC > Dave Rempel <> drempel@qnx.com> > wrote:
BC > DR > Bill Caroselli wrote:My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > DR > Yes, using PtBlit()BC > I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.BC > Also on my main window I have a PtButton I’ve added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.BC > The blitting is working, BUT the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.BC > Why is the draw function being called?
BC > I’m using blitting because I don’t want to redraw the whole thing!
BC > The button that I’m clicking does not over lap PtPanelGrou in any way.
–
Wojtek Lerch QNX Software Systems Ltd.
Duah!
It makes sense. OK. Thanks.
Steve, you might want to document that!
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > Bill Caroselli <qtps@earthlink.net> wrote:
Can someone at QSSL take a stab at this?
WL > PtBlit() damages the portion of the source rectangle that doesn’t
WL > overlap with the destination rectangle. For instance, if you’re
WL > blitting by one pixel to the right, it’ll damage a one-pixel strip along
WL > the left adge of the rectangle.
WL > It also will damage any portions of the destination area where the
WL > corresponding source area is invisible (i.e. outside of the canvas; I
WL > don’t think we handle cases where there’s another widget on top of the
WL > one you’re blitting). For instance, if you take a huge rectangle and
WL > blit it by one pixel to the left, it’ll damage a one-pixel strip along
WL > the right edge of the canvas.
Bill Caroselli wrote:
I’m still waiting to find out why PtBlit() is damaging my widget
(I.E. forcing my draw_f() function ot be called.
Wojtek got that one…
I have a new problem.
In my draw function I call:
PhRect_t my_rect;
PtCalcCanvas( widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
where ‘widget’ is from the draw callback, and this works. Everything I
draw is where I expect it to be.Later in the program some external event occurs and I try to display a
new object on the PtRaw widget. I call:
PhRect_t my_rect;
PtCalcCanvas( ABW_my_widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
but the translation is off. I.E. it draws too high. Above my PtRaw
widget actually. Note: I left the clipping off just so I could see
where it was drawing.Why is my translation wrong?
In th PgSetTranslation(), PgRELATIVE is relative to what?
Note: there is no telling what widget had focus when the additional
draw was attempted.
The Translation is relative to the translation in the current GC. What
I think you really want to do is set some state on your PtRaw widget
(see “Storing arbitrary user data” in the doc’s for PtWidget) that means
that you want to draw this new object. Then call PtDamageWidget on your
PtRaw so it get’s drawn in the proper order (the current translation
should be what you expect it to be, as will be the clipping).
Bill Caroselli <> qtps@earthlink.net> > wrote:
BC > Bill Caroselli <> qtps@earthlink.net> > wrote:
BC > BC > Dave Rempel <> drempel@qnx.com> > wrote:
BC > BC > DR > Bill Caroselli wrote:My thoughts were this:
- Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > BC > DR > Yes, using PtBlit()BC > BC > I’m using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > BC > inside of my main window.BC > BC > Also on my main window I have a PtButton I’ve added for diagnostic
BC > BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > BC > row.BC > BC > The blitting is working, BUT the draw function for my PtRaw is also
BC > BC > being called. Nothing should be damaging the widget.BC > BC > Why is the draw function being called?
BC > BC > I’m using blitting because I don’t want to redraw the whole thing!
BC > BC > The button that I’m clicking does not over lap PtPanelGrou in any way.BC > I did a little more research. It is the call to PtBlit that is
BC > damaging the widget. If I comment out the PtBlit() call then my draw
BC > function does not get called.BC > What am I doing wrong?
Dave Rempel <drempel@qnx.com> wrote:
DR > Bill Caroselli wrote:
I have a new problem.
Why is my translation wrong?
DR > The Translation is relative to the translation in the current GC. What
DR > I think you really want to do is set some state on your PtRaw widget
DR > (see “Storing arbitrary user data” in the doc’s for PtWidget) that means
DR > that you want to draw this new object. Then call PtDamageWidget on your
DR > PtRaw so it get’s drawn in the proper order (the current translation
DR > should be what you expect it to be, as will be the clipping).
Ouch!
My PtRaw is very complicated (i.e. many graphical objects). When some
external event occurs I merely want to draw one more dot on the screen,
and possibly erase one (draw it with background color and then draw the
adjacent dots).
If I damage the widget then I have to redraw all the dots. There can
be as many as 10,000 (more likely 3000 to 5000). And I want to do this
10 times a second. I can’t draw the whole PtRaw 10 times a second.
The system isn’t fast enough.
So, can I know the correct graphics context to draw my dots into?
Or, can my non-photon code somehow call a user defined callback for my
PtRaw widget? (That would force the correct GC right?)
Bill Caroselli wrote:
Dave Rempel <> drempel@qnx.com> > wrote:
DR > Bill Caroselli wrote:I have a new problem.
Why is my translation wrong?
DR > The Translation is relative to the translation in the current GC. What
DR > I think you really want to do is set some state on your PtRaw widget
DR > (see “Storing arbitrary user data” in the doc’s for PtWidget) that means
DR > that you want to draw this new object. Then call PtDamageWidget on your
DR > PtRaw so it get’s drawn in the proper order (the current translation
DR > should be what you expect it to be, as will be the clipping).Ouch!
My PtRaw is very complicated (i.e. many graphical objects). When some
external event occurs I merely want to draw one more dot on the screen,
and possibly erase one (draw it with background color and then draw the
adjacent dots).If I damage the widget then I have to redraw all the dots. There can
be as many as 10,000 (more likely 3000 to 5000). And I want to do this
10 times a second. I can’t draw the whole PtRaw 10 times a second.
The system isn’t fast enough.
Generally a widget’s draw function shouldn’t do a lot of work (this
includes PtRaw’s). Given that, then what I think you want to do is
create an offscreen context to hold what your PtRaw should currently
look like (PdCreateOffscreenContext()). You can then update the
offscreen context to look like what ever you want, when ever you want.
In your PtRaw’s draw function you call PgContextBlit or
PgContextBlitArea to copy the contents of the offscreen context to the
location of your PtRaw widget’s canvas. You can be even smarter about
it and look at the damage rects (remember to look starting at the second
one, since the first damage rect is always the entire canvas) and copy
just the portions you need. Offscreen Contexts are hardware
accelerated, so they are better than PhImage_t’s and Memory Context’s
generally. The other change you would have to do is instead of using
PtBlit you’d have to use PgContextBlit with the offscreen context as the
source and destination contexts. IIRC you are also using a
PtOSContainer already, you probably won’t need it if you are using this
method to reduce flicker, but if you still need it for other reasons,
make sure that in your widget draw function that you call
PhDCGetCurrent() for the destination context parameter of
PgContextBlit(), since you will be wanting to blit to the OSContainers’s
offscreen context, not the actual display (OS Container’s offscreen
context needs to kept up to date so that it can handle exposes
correctly). It’s generally good practice to use PhDCGetCurrent() for
blitting to the “screen” instead of NULL anyways.
Look at “Raw Drawing and Animation: Video Memory Offscreen” for
examples of using an offscreen context.
So, can I know the correct graphics context to draw my dots into?
Or, can my non-photon code somehow call a user defined callback for my
PtRaw widget? (That would force the correct GC right?)
No, there is only (generally) one GC that gets used by the widget
engine, and it’s translation and clipping is constantly changing, so the
only way for it to be gaurunteed to be correct is in the widgets draw
function when the widget engine calls it.
Oops, this part came out completely wrong…
“(remember to look starting at the second one, since the first damage
rect is always the entire canvas)”
I meant to start walking the list using the second rect if it’s there,
otherwise use the first…
Dave