i found the problem...
you did not allocate a big enough window...
On Wed, Jan 15, 2014 at 9:19 PM, Conor Williams wrote:
> did you divide by 10?
>
>
> On Wed, Jan 15, 2014 at 7:08 PM, wrote:
>
>> its wrong.
>>
>> look at the code comments. it draws the same thing twice. one time,
>> on to a o
did you divide by 10?
On Wed, Jan 15, 2014 at 7:08 PM, wrote:
> its wrong.
>
> look at the code comments. it draws the same thing twice. one time,
> on to a offscreen image and one time on screen (a layer) directly.
>
> they should be identical, they are not.
>
> comment out the 2nd one to see
its wrong.
look at the code comments. it draws the same thing twice. one time,
on to a offscreen image and one time on screen (a layer) directly.
they should be identical, they are not.
comment out the 2nd one to see how its supposed to look.
it should be just a blue rectangle overlapping a red
i don't see anything obvious in this image. do you?
note: i'm using a derivative of russ' p9p memdraw which
corrected a number of things noted mostly by andre a
few years ago.
- erik<>
ack
On Wed, Jan 15, 2014 at 7:52 AM, wrote:
> yes, this illustrates the issue. the big red hook inside the rectangle
> shouldnt be there.
>
> after sysupdate, rebuild libmemlayer, then rebuild of the kernel and
> install it. then rerun the test program and you should get a different
> picture.
yes, this illustrates the issue. the big red hook inside the rectangle
shouldnt be there.
after sysupdate, rebuild libmemlayer, then rebuild of the kernel and
install it. then rerun the test program and you should get a different
picture.
--
cinap
this is what I get after compiling your code cinap
On Mon, Dec 9, 2013 at 4:09 AM, wrote:
> when drawing a replicated source image with a clipr with
> clipr.min > Pt(0, 0), drawclip() would translate the
> src->clipr on the dstr but then clamp the source rectangle
> back on src->r.
>
> this c
On Mon, 9 Dec 2013, Conor Williams wrote:
ok... i'm now interested... is there a hot boot plan 9 yet?
9front.org and also whatever our google code url is.
--
Veety
that would mean chaning documented behaviour of drawclip()...
then i'd have to fix the callers of drawclip() as well.
keeping drawclip()'s behaviour as it is seemed to be the
safest option. and moving the source and mask rects to
src->r and mask->r makes sense in the context of working
on flat bit
> in 9front, i added drawclipnorepl() function that is like drawclip() but does
> not clamp
> the source and mask rectangles to be in src->r and mask->r and use it in
> libmemlayer.
why can't you fix the existing function?
- erik
On Mon Dec 9 01:23:23 EST 2013, conor.willi...@gmail.com wrote:
> ok... i'm now interested... is there a hot boot plan 9 yet?
http://ftp.9atom.org/other/usbinstamd64.bz2
- erik
ok... i'm now interested... is there a hot boot plan 9 yet?
On Mon, Dec 9, 2013 at 6:09 AM, Matthew Veety wrote:
>
>
> > On Dec 9, 2013, at 0:28, Conor Williams
> wrote:
> >
> > and what's wrong with that?
>
> It's not supposed to do that.
>
> --
> Veety
>
>
> On Dec 9, 2013, at 0:28, Conor Williams wrote:
>
> and what's wrong with that?
It's not supposed to do that.
--
Veety
and what's wrong with that?
On Mon, Dec 9, 2013 at 5:00 AM, wrote:
> just compile it.
>
> basically the 2nd part of the code is supposed to look like the first.
>
> the difference is just that the first part uses an intermediate image,
> the 2nd part draws directly on the screen image (a layer)
just compile it.
basically the 2nd part of the code is supposed to look like the first.
the difference is just that the first part uses an intermediate image,
the 2nd part draws directly on the screen image (a layer).
without the fix, you get a 4 pixel red hook inside the blue rect.
with the fi
have you a screen shot? can you do attachments on this group??
On Mon, Dec 9, 2013 at 4:09 AM, wrote:
> when drawing a replicated source image with a clipr with
> clipr.min > Pt(0, 0), drawclip() would translate the
> src->clipr on the dstr but then clamp the source rectangle
> back on src->r.
16 matches
Mail list logo
