[9fans] libmemlayer bug

[9fans] libmemlayer bug

[cinap_lenrek]

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 causes problems in libmemlayer when it drawclips() at each iteration
when traversing down the layers. the clamping of sr back to src->r (which is 1x1
in the example below) it will shift the destination rectangle to the right
as it is reapplied at each loop iteration.

#include <u.h>
#include <libc.h>
#include <draw.h>

Image *blue;
Image *red;

void
main(int, char *argv[])
{
        Image *i;

        if(initdraw(nil, nil, argv[0]) < 0)
                sysfatal("initdraw: %r");
        i = allocimage(display, screen->r, screen->chan, 1, DWhite);

        red = allocimage(display, Rect(0,0,1,1), screen->chan, 1, DRed);
        blue = allocimage(display, Rect(0,0,1,1), screen->chan, 1, DPaleblue);
        replclipr(red, 1, Rect(10, 10, 110, 110));
        replclipr(blue, 1, Rect(11, 11, 111, 111));

        /* draw on non-layer, works correctly */
        draw(i, i->r, red, nil, ZP);
        draw(i, i->r, blue, nil, ZP);
        draw(screen, screen->r, i, nil, i->r.min);
        flushimage(display, 1);

        /* draw on (screen) layer is too far to the right */
        draw(screen, screen->r, red, nil, ZP);
        draw(screen, screen->r, blue, nil, ZP);
        flushimage(display, 1);

        for(;;){
                sleep(1000);
        }
}

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.

http://code.google.com/p/plan9front/source/detail?r=c18ae5b7ea0ee138080824c4f164628f899b7770

--
cinap

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

have you a screen shot? can you do attachments on this group??


On Mon, Dec 9, 2013 at 4:09 AM, <cinap_lenrek@felloff.net> 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 causes problems in libmemlayer when it drawclips() at each iteration
> when traversing down the layers. the clamping of sr back to src->r (which
> is 1x1
> in the example below) it will shift the destination rectangle to the right
> as it is reapplied at each loop iteration.
>
> #include <u.h>
> #include <libc.h>
> #include <draw.h>
>
> Image *blue;
> Image *red;
>
> void
> main(int, char *argv[])
> {
>         Image *i;
>
>         if(initdraw(nil, nil, argv[0]) < 0)
>                 sysfatal("initdraw: %r");
>         i = allocimage(display, screen->r, screen->chan, 1, DWhite);
>
>         red = allocimage(display, Rect(0,0,1,1), screen->chan, 1, DRed);
>         blue = allocimage(display, Rect(0,0,1,1), screen->chan, 1,
> DPaleblue);
>         replclipr(red, 1, Rect(10, 10, 110, 110));
>         replclipr(blue, 1, Rect(11, 11, 111, 111));
>
>         /* draw on non-layer, works correctly */
>         draw(i, i->r, red, nil, ZP);
>         draw(i, i->r, blue, nil, ZP);
>         draw(screen, screen->r, i, nil, i->r.min);
>         flushimage(display, 1);
>
>         /* draw on (screen) layer is too far to the right */
>         draw(screen, screen->r, red, nil, ZP);
>         draw(screen, screen->r, blue, nil, ZP);
>         flushimage(display, 1);
>
>         for(;;){
>                 sleep(1000);
>         }
> }
>
> 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.
>
>
> http://code.google.com/p/plan9front/source/detail?r=c18ae5b7ea0ee138080824c4f164628f899b7770
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 2649 bytes --]

Re: [9fans] libmemlayer bug

[cinap_lenrek]

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 fix, theres just a red and a blue rectangle one pixel
shifted apart and the blue one is overlapping the red one.

--
cinap

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

and what's wrong with that?


On Mon, Dec 9, 2013 at 5:00 AM, <cinap_lenrek@felloff.net> 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).
>
> without the fix, you get a 4 pixel red hook inside the blue rect.
>
> with the fix, theres just a red and a blue rectangle one pixel
> shifted apart and the blue one is overlapping the red one.
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 902 bytes --]

Re: [9fans] libmemlayer bug

[Matthew Veety]

> On Dec 9, 2013, at 0:28, Conor Williams <conor.williams@gmail.com> wrote:
>
> and what's wrong with that?

It's not supposed to do that.

--
Veety

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

ok... i'm now interested... is there a hot boot plan 9 yet?


On Mon, Dec 9, 2013 at 6:09 AM, Matthew Veety <mveety@gmail.com> wrote:

>
>
> > On Dec 9, 2013, at 0:28, Conor Williams <conor.williams@gmail.com>
> wrote:
> >
> > and what's wrong with that?
>
> It's not supposed to do that.
>
> --
> Veety
>
>

[-- Attachment #2: Type: text/html, Size: 733 bytes --]

Re: [9fans] libmemlayer bug

[erik quanstrom]

On Mon Dec  9 01:23:23 EST 2013, conor.williams@gmail.com wrote:

> ok... i'm now interested... is there a hot boot plan 9 yet?

http://ftp.9atom.org/other/usbinstamd64.bz2

- erik

Re: [9fans] libmemlayer bug

[Matthew Veety]

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

Re: [9fans] libmemlayer bug

[erik quanstrom]

> 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

Re: [9fans] libmemlayer bug

[cinap_lenrek]

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 bitmaps.

there also was no way to fixup the result after drawclip() in
libmemlayers memdraw() without duplicating the functionaliry.

--
cinap

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1.1: Type: text/plain, Size: 2034 bytes --]

this is what I get after compiling your code cinap




On Mon, Dec 9, 2013 at 4:09 AM, <cinap_lenrek@felloff.net> 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 causes problems in libmemlayer when it drawclips() at each iteration
> when traversing down the layers. the clamping of sr back to src->r (which
> is 1x1
> in the example below) it will shift the destination rectangle to the right
> as it is reapplied at each loop iteration.
>
> #include <u.h>
> #include <libc.h>
> #include <draw.h>
>
> Image *blue;
> Image *red;
>
> void
> main(int, char *argv[])
> {
>         Image *i;
>
>         if(initdraw(nil, nil, argv[0]) < 0)
>                 sysfatal("initdraw: %r");
>         i = allocimage(display, screen->r, screen->chan, 1, DWhite);
>
>         red = allocimage(display, Rect(0,0,1,1), screen->chan, 1, DRed);
>         blue = allocimage(display, Rect(0,0,1,1), screen->chan, 1,
> DPaleblue);
>         replclipr(red, 1, Rect(10, 10, 110, 110));
>         replclipr(blue, 1, Rect(11, 11, 111, 111));
>
>         /* draw on non-layer, works correctly */
>         draw(i, i->r, red, nil, ZP);
>         draw(i, i->r, blue, nil, ZP);
>         draw(screen, screen->r, i, nil, i->r.min);
>         flushimage(display, 1);
>
>         /* draw on (screen) layer is too far to the right */
>         draw(screen, screen->r, red, nil, ZP);
>         draw(screen, screen->r, blue, nil, ZP);
>         flushimage(display, 1);
>
>         for(;;){
>                 sleep(1000);
>         }
> }
>
> 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.
>
>
> http://code.google.com/p/plan9front/source/detail?r=c18ae5b7ea0ee138080824c4f164628f899b7770
>
> --
> cinap
>
>

[-- Attachment #1.2: Type: text/html, Size: 2667 bytes --]

[-- Attachment #2: cinap1.jpg --]
[-- Type: image/jpeg, Size: 23271 bytes --]

Re: [9fans] libmemlayer bug

[cinap_lenrek]

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

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

ack


On Wed, Jan 15, 2014 at 7:52 AM, <cinap_lenrek@felloff.net> 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.
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 680 bytes --]

Re: [9fans] libmemlayer bug

[erik quanstrom]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

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

[-- Attachment #2: w.png --]
[-- Type: image/png, Size: 2481 bytes --]

Re: [9fans] libmemlayer bug

[cinap_lenrek]

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 one (one
pixel shifted apart).

--
cinap

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

did you divide by 10?


On Wed, Jan 15, 2014 at 7:08 PM, <cinap_lenrek@felloff.net> 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 how its supposed to look.
>
> it should be just a blue rectangle overlapping a red one (one
> pixel shifted apart).
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 814 bytes --]

Re: [9fans] libmemlayer bug

[Conor Williams]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

i found the problem...

you did not allocate a big enough window...


On Wed, Jan 15, 2014 at 9:19 PM, Conor Williams <conor.williams@gmail.com>wrote:

> did you divide by 10?
>
>
> On Wed, Jan 15, 2014 at 7:08 PM, <cinap_lenrek@felloff.net> 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 how its supposed to look.
>>
>> it should be just a blue rectangle overlapping a red one (one
>> pixel shifted apart).
>>
>> --
>> cinap
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1345 bytes --]