Re: [SerialICE] r80 - trunk/qemu-0.11.0

[Stefan Reinauer]

On 12/2/09 11:59 PM, [e-mail] wrote:
> This is awsome :-)
> I can't wait to try it out.
>
> It seems to be a rather large (file size) banner though. Any way to scale it
> down a bit?
>
> Thanks - Joe

Not so easily...

I made the graphics 320x200, so it's around 230KiB raw image data.

Options:
- use a compressed format.. This would mean adding a (i.e. JPG)
decompressor to Qemu..
   Either by requiring to link against libjpeg, or by adding a jpg
decompressor in an extra file.
- load the PPM file from the filesystem instead of including it in the
source. Doesn't make it
  smaller but then it's not possible to make a single diff against the
Qemu source tree anymore.
- paint something funky with a nice and small algorithm. Suggestions?

Stefan

r80 - trunk/qemu-0.11.0

[Alexander Graf]

Stefan Reinauer wrote:
> On 12/2/09 11:59 PM, [e-mail] wrote:
> > This is awsome :-)
> > I can't wait to try it out.
> >
> > It seems to be a rather large (file size) banner though. Any way to scale it
> > down a bit?
> >
> > Thanks - Joe
>
> Not so easily...
>
> I made the graphics 320x200, so it's around 230KiB raw image data.
>
> Options:
> use a compressed format.. This would mean adding a (i.e. JPG)
>
> decompressor to Qemu..
>    Either by requiring to link against libjpeg, or by adding a jpg
> decompressor in an extra file.
> load the PPM file from the filesystem instead of including it in the
>
> source. Doesn't make it
>   smaller but then it's not possible to make a single diff against the
> Qemu source tree anymore.
> paint something funky with a nice and small algorithm. Suggestions?

Good old zlib should give you pretty good compression ratios.

Alex

r80 - trunk/qemu-0.11.0

[Maciej Pijanka]

On Thu, 03 Dec 2009, Stefan Reinauer wrote:
> On 12/2/09 11:59 PM, [e-mail] wrote:
> > This is awsome :-)
> > I can't wait to try it out.
> >
> > It seems to be a rather large (file size) banner though. Any way to scale it
> > down a bit?
> >
> > Thanks - Joe
>
> Not so easily...
>
> I made the graphics 320x200, so it's around 230KiB raw image data.
>
> Options:
> use a compressed format.. This would mean adding a (i.e. JPG)
>
> decompressor to Qemu..
>    Either by requiring to link against libjpeg, or by adding a jpg
> decompressor in an extra file.
> load the PPM file from the filesystem instead of including it in the
>
> source. Doesn't make it
>   smaller but then it's not possible to make a single diff against the
> Qemu source tree anymore.
> paint something funky with a nice and small algorithm. Suggestions?

Maybe fractal with simple SerialICE drawn on it?
(even simple fractal)

not even updating, or something, or some game of life would be an option?

r80 - trunk/qemu-0.11.0

[Stefan Reinauer]

On 12/3/09 5:49 PM, Alexander Graf wrote:
> Stefan Reinauer wrote:
> > I made the graphics 320x200, so it's around 230KiB raw image data.
> >
> > Options:
> > use a compressed format.. This would mean adding a (i.e. JPG)
> >
> > decompressor to Qemu..
> >    Either by requiring to link against libjpeg, or by adding a jpg
> > decompressor in an extra file.
> > load the PPM file from the filesystem instead of including it in the
> >
> > source. Doesn't make it
> >   smaller but then it's not possible to make a single diff against the
> > Qemu source tree anymore.
> > paint something funky with a nice and small algorithm. Suggestions?
>
> Good old zlib should give you pretty good compression ratios.

Unfortunately, for the current picture it goes down from 230KiB to
180KiB, almost not worth the effort. The same image as jpg is 29KiB.

Stefan

r80 - trunk/qemu-0.11.0

[Alexander Graf]

On 03.12.2009, at 18:42, Stefan Reinauer wrote:
> On 12/3/09 5:49 PM, Alexander Graf wrote:
> > Stefan Reinauer wrote:
> > > I made the graphics 320x200, so it's around 230KiB raw image data.
> > >
> > > Options:
> > > use a compressed format.. This would mean adding a (i.e. JPG)
> > >
> > > decompressor to Qemu..
> > >   Either by requiring to link against libjpeg, or by adding a jpg
> > > decompressor in an extra file.
> > > load the PPM file from the filesystem instead of including it in the
> > >
> > > source. Doesn't make it
> > >  smaller but then it's not possible to make a single diff against the
> > > Qemu source tree anymore.
> > > paint something funky with a nice and small algorithm. Suggestions?
> >
> > Good old zlib should give you pretty good compression ratios.
>
> Unfortunately, for the current picture it goes down from 230KiB to
> 180KiB, almost not worth the effort. The same image as jpg is 29KiB.

Oh? Do you have many color fadings?

Got a link to the image?

Alex

r80 - trunk/qemu-0.11.0

On December 3, 2009 at 4:24 PM Stefan Reinauer  wrote:
> On 12/2/09 11:59 PM, [e-mail] wrote:
> > This is awsome :-)
> > I can't wait to try it out.
> >
> > It seems to be a rather large (file size) banner though. Any way to scale it
> > down a bit?
> >
> > Thanks - Joe
>
> Not so easily...
>
> I made the graphics 320x200, so it's around 230KiB raw image data.
>
> Options:
> use a compressed format.. This would mean adding a (i.e. JPG)
>
> decompressor to Qemu..
>     Either by requiring to link against libjpeg, or by adding a jpg
> decompressor in an extra file.
> load the PPM file from the filesystem instead of including it in the
>
> source. Doesn't make it
>    smaller but then it's not possible to make a single diff against the
> Qemu source tree anymore.
> paint something funky with a nice and small algorithm. Suggestions?

Ah, 230k isn't so bad and serialice is small enough so there is plenty of space
left over. The only time it may be a problem is if you only have a 128k chip. I
was just looking at the 1.4mb attachment to r80 but I guess that was the raw hex
data.

Thanks - Joe