[9fans] jpg image too big

[9fans] jpg image too big

[erik quanstrom]

the problem is indeed drawterm related, but it's not dt's
fault.

the problem is that devdraw/loadimage.c needs to load
at least 1 scan line at a time.  unfortunately, iounit for
drawterm ends up being 8k, so display->bufsize=8k.  the
problem is that each scan line is over 9k in my case.

i haven't looked yet to see if the kernel can deal with
partial lines, or what could be done about the too-small
iounit.  but it would seem to me that something has to
give.

- erik

Re: [9fans] jpg image too big

[Russ Cox]

On Tue, Oct 20, 2009 at 5:04 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> the problem is that devdraw/loadimage.c needs to load
> at least 1 scan line at a time.  unfortunately, iounit for
> drawterm ends up being 8k, so display->bufsize=8k.  the
> problem is that each scan line is over 9k in my case.
>
> i haven't looked yet to see if the kernel can deal with
> partial lines, or what could be done about the too-small
> iounit.  but it would seem to me that something has to
> give.

you can handle this in loadimage by turning a single
call with too much data per scan line into multiple
calls, each delivering a fraction of a scan line
(there is a rectangle argument that says what subsection
of the image is being loaded).

russ

Re: [9fans] jpg image too big

[erik quanstrom]

> > i haven't looked yet to see if the kernel can deal with
> > partial lines, or what could be done about the too-small
> > iounit.  but it would seem to me that something has to
> > give.
>
> you can handle this in loadimage by turning a single
> call with too much data per scan line into multiple
> calls, each delivering a fraction of a scan line
> (there is a rectangle argument that says what subsection
> of the image is being loaded).

oh, great.  i just didn't know if that was legal.
is it also possible to lock the display and send
more than iounit's data?

- erik

Re: [9fans] jpg image too big

[Russ Cox]

> oh, great.  i just didn't know if that was legal.
> is it also possible to lock the display and send
> more than iounit's data?

devdraw expects the messages to be delivered whole
in each write, so you'd have to introduce a buffer to
hold partial messages or be able to process partial
writes.  much easier to tweak loadimage.

even easier would be to tweak drawterm so that it
ends up with a larger iounit.  i'm pretty sure devdraw's
iounit is bigger and also that we bumped up the block
size in cpu (looks like 64 kB) for exactly this reason.

russ

Re: [9fans] jpg image too big

[erik quanstrom]

> even easier would be to tweak drawterm so that it
> ends up with a larger iounit.  i'm pretty sure devdraw's
> iounit is bigger and also that we bumped up the block
> size in cpu (looks like 64 kB) for exactly this reason.

good point.  can we just make i/o unit anything we wish?
maybe it's old 9p hangover, but i have this nagging feeling
about network-dependant limits.

in looking at the code, it might be a lot more efficent
for loadimage to count pixels rather than lines (being
careful with the slop at the end, of course).  the
slop is Dy(r)-1 pixels, which is considerable for a
camera shot.

maybe it's not worth the pain?

- erik

Re: [9fans] jpg image too big

[Russ Cox]

> good point.  can we just make i/o unit anything we wish?

no, because it affects the size of buffer
that gets allocated to hold 9p messages.
the kernel is free to limit the iounit too.

> in looking at the code, it might be a lot more efficent
> for loadimage to count pixels rather than lines (being
> careful with the slop at the end, of course).  the
> slop is Dy(r)-1 pixels, which is considerable for a
> camera shot.
>
> maybe it's not worth the pain?

it's not.  fix iounit.