nanogui: Thread: [nanogui] GrCopyArea


[<<] [<] Page 1 of 1 [>] [>>]
Subject: [nanogui] GrCopyArea
From: Ib ####@####.####
Date: 15 Aug 2001 15:14:13 -0000
Message-Id: <510819110362D211ABFD00A0C9A2BE4A012D447A@mail.visionik.dk>

Hi all
We are using GrCopyArea to draw pixmaps on the screen and this works out
very nicely. We would however like to not copy one specific colour. 
This seems to be possible since GrCopyArea takes a ROP to pass to the
blitter, and in mwtypes.h we find the following definition:

/* copy src -> dst except for transparent color in src*/
#define MWROP_SRCTRANSCOPY	0x01000000L

Just what we need. Now our problem is to set the correct transparent color
in the appropriate struct. This should be a  MWIMAGEHDR. - but we only have
an id to the pixmap we are using - how do we get to the appropriate header?



> Ib Jørgensen  Lead Technical Consultant
> --------------------------------------------------------------
> AGENCY.COM Interactive TV
> 
> Islands Brygge 57, DK 2300 Copenhagen S
> T: +45 36 93 60 00  F: +45 36 93 30 01  
> Direct: +45 36 93 60 88 
> E: ####@####.####  www.agency.com
> 
> 
Subject: Re: [nanogui] GrCopyArea
From: Jordan Crouse ####@####.####
Date: 15 Aug 2001 15:26:49 -0000
Message-Id: <01081509270805.21329@cosmic>

Unfortunately, while MWROP_SRCTRANSCOPY is defined, it has never been 
implemented.  Hopefully this will get changed soon, as there are lots of 
people interested in getting this working.  I don't know who specified these 
defines in the first place (Greg, Alex??) but obviously somebody was 
intending to get them working in the future.

A pixmap is very different from an MWIMAGEHDR.  A pixmap is a drawable window 
that is not drawn on the screen, but rather implemented in memory.  It can be 
drawn to just like a window.  A MWIMAGEHDR (or GR_IMAGE_HDR for clients) is a 
structure that contains information about an image.  These two items are 
completely different, and not associated in any way.  

Jordan

On Wednesday 15 August 2001 09:14, Ib Jørgensen mentioned:
> Hi all
> We are using GrCopyArea to draw pixmaps on the screen and this works out
> very nicely. We would however like to not copy one specific colour.
> This seems to be possible since GrCopyArea takes a ROP to pass to the
> blitter, and in mwtypes.h we find the following definition:
>
> /* copy src -> dst except for transparent color in src*/
> #define MWROP_SRCTRANSCOPY	0x01000000L
>
> Just what we need. Now our problem is to set the correct transparent color
> in the appropriate struct. This should be a  MWIMAGEHDR. - but we only have
> an id to the pixmap we are using - how do we get to the appropriate header?
>
> > Ib Jørgensen  Lead Technical Consultant
> > --------------------------------------------------------------
> > AGENCY.COM Interactive TV
> >
> > Islands Brygge 57, DK 2300 Copenhagen S
> > T: +45 36 93 60 00  F: +45 36 93 30 01
> > Direct: +45 36 93 60 88
> > E: ####@####.####  www.agency.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
Subject: Re: [nanogui] GrCopyArea
From: "Greg Haerr" ####@####.####
Date: 15 Aug 2001 16:22:29 -0000
Message-Id: <088201c125a5$888c1d40$3aba46a6@xmission.com>

/* copy src -> dst except for transparent color in src*/
#define MWROP_SRCTRANSCOPY 0x01000000L

Just what we need. Now our problem is to set the correct transparent color
in the appropriate struct. This should be a  MWIMAGEHDR. - but we only have
an id to the pixmap we are using - how do we get to the appropriate header?

-- As Jordan said, there aren't yet transparent blitters implemented
in the fblin*.c files, so this won't work yet.  The first fix is to implement
the ROP case in your fblinXXX.c driver.  Then, you should (once)
copy the image into a GrNewPixmap, and destroy the image id.  At that
point, you can use GrCopyArea with an ROP (since the pixmap is
based on a PSD), which will end up passing the ROP to the 
driver blit function.

Regards,

Greg



Subject: Re: [nanogui] GrCopyArea
From: Jordan Crouse ####@####.####
Date: 15 Aug 2001 16:51:16 -0000
Message-Id: <01081510512608.21329@cosmic>

How would one set the "transparent" color?

On Wednesday 15 August 2001 10:15, Greg Haerr mentioned:
> /* copy src -> dst except for transparent color in src*/
> #define MWROP_SRCTRANSCOPY 0x01000000L
>
> Just what we need. Now our problem is to set the correct transparent color
> in the appropriate struct. This should be a  MWIMAGEHDR. - but we only have
> an id to the pixmap we are using - how do we get to the appropriate header?
>
> -- As Jordan said, there aren't yet transparent blitters implemented
> in the fblin*.c files, so this won't work yet.  The first fix is to
> implement the ROP case in your fblinXXX.c driver.  Then, you should (once)
> copy the image into a GrNewPixmap, and destroy the image id.  At that
> point, you can use GrCopyArea with an ROP (since the pixmap is
> based on a PSD), which will end up passing the ROP to the
> driver blit function.
>
> Regards,
>
> Greg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
Subject: Re: [nanogui] GrCopyArea
From: "Greg Haerr" ####@####.####
Date: 15 Aug 2001 16:54:19 -0000
Message-Id: <08e701c125a9$f925f680$3aba46a6@xmission.com>

: How would one set the "transparent" color?
: 
: On Wednesday 15 August 2001 10:15, Greg Haerr mentioned:
: > /* copy src -> dst except for transparent color in src*/
: > #define MWROP_SRCTRANSCOPY 0x01000000L

Hmmm.  Good question.  Suggest either a GC setting or having
an argument/structure with GrCopyAreaEx.

Regards,

Greg


Subject: GrCopyArea
From: George Goh ####@####.####
Date: 9 Aug 2004 16:17:43 +0100
Message-Id: <1092064649.2634.48.camel@LinuxDev1>

I'm puzzled by the behaviour of GrCopyArea. It doesn't seem to be bound
by the width and height parameters that I give it.

I have created an onscreen window(GrNewWindow) which is 640x480, with a
target area of 300x300. I've also created an offscreen drawing
area(GrNewPixmap) of 300x600. Now when I try to copy using
GrCopyArea(window_onscreen, gc, 100,100,300,300, offscreen_area, 0,0,0),
the area that gets copied is larger than 300x300, in fact, the area of
the screen written is width 300, height until the bottom of the window.

How do I make GrCopyArea only copy the area I want it to, and clip off
any extra that may exist in the source?

Thanks,
George

Subject: Re: [nanogui] GrCopyArea
From: "Greg Haerr" ####@####.####
Date: 10 Aug 2004 01:51:11 +0100
Message-Id: <03c701c47e74$156ba9e0$3eba46a6@winXP>

: I have created an onscreen window(GrNewWindow) which is 640x480, with a
: target area of 300x300. I've also created an offscreen drawing
: area(GrNewPixmap) of 300x600. Now when I try to copy using
: GrCopyArea(window_onscreen, gc, 100,100,300,300, offscreen_area, 0,0,0),
: the area that gets copied is larger than 300x300, in fact, the area of
: the screen written is width 300, height until the bottom of the window.

So you're saying that the width is correct, but the height is 380, 
rather than 300?


: How do I make GrCopyArea only copy the area I want it to, and clip off
: any extra that may exist in the source?


Hmm..  Double check your code, and take a look at the
engine implementation, src/nanox/srvfunc.c::GrCopyArea, and
then engine/devdraw.c::GdBlit.  I'm pretty sure that the width/height
passed to the GrCopyArea call is used to set both the size of the
clipped src area as well as the destination rectangle.

Regards,

Greg

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.