* Re: [9fans] jpg image too big
[not found] <<dd6fe68a0910200755nb397fc5jaef44a12fa3ad049@mail.gmail.com>
@ 2009-10-20 15:04 ` erik quanstrom
2009-10-20 15:16 ` Russ Cox
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2009-10-20 15:04 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] jpg image too big
2009-10-20 15:04 ` [9fans] jpg image too big erik quanstrom
@ 2009-10-20 15:16 ` Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2009-10-20 15:16 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] jpg image too big
2009-10-20 14:14 ` erik quanstrom
@ 2009-10-20 14:55 ` Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2009-10-20 14:55 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] jpg image too big
[not found] <<dd6fe68a0910200700g6e876655o53bb23274f335b11@mail.gmail.com>
@ 2009-10-20 14:14 ` erik quanstrom
2009-10-20 14:55 ` Russ Cox
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2009-10-20 14:14 UTC (permalink / raw)
To: 9fans
> > 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] jpg image too big
2009-10-20 12:04 erik quanstrom
@ 2009-10-20 14:00 ` Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2009-10-20 14:00 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [9fans] jpg image too big
@ 2009-10-20 12:04 erik quanstrom
2009-10-20 14:00 ` Russ Cox
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2009-10-20 12:04 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-10-20 15:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <<dd6fe68a0910200755nb397fc5jaef44a12fa3ad049@mail.gmail.com>
2009-10-20 15:04 ` [9fans] jpg image too big erik quanstrom
2009-10-20 15:16 ` Russ Cox
[not found] <<dd6fe68a0910200700g6e876655o53bb23274f335b11@mail.gmail.com>
2009-10-20 14:14 ` erik quanstrom
2009-10-20 14:55 ` Russ Cox
2009-10-20 12:04 erik quanstrom
2009-10-20 14:00 ` Russ Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).