headers
Max Carlson | 1 Feb 2005 08:15

Re: Performance Optimizations ...

The LPS does the conversion for you.  Provided you have caching turned 
on (it's on by default) the performance hit should only happen the first 
time the image is requested.  In general, it's not an issue unless each 
user will be downloading unique images.

If you did the conversion manually, you would get a slight performance 
gain for the first load.  Another option is to write a script that 
prefills the LPS cache by requesting each JPEG through the LPS.  Either 
one of these options would require some work on your part.

Note that 3.0+ will have the serverless deployment option.  This means 
the compiled app will be able to download JPEG files directly to the 
client without requiring conversion to .swf.  This is probably the best 
option for you, if you can wait for the official release.

Regards,
Max Carlson
Laszlo Studios

Jon Gilkison wrote:
> I'm sure a lot of people have seen the application I'm developing
> (over 84 logins from the Laszlo mailing lists).  Anyways, as a
> refresher, I'm loading a lot of external media (all JPEGs) based on
> the results of a database.
> 
> I was wondering if it'd be in my best interests to convert those
> jpeg's to SWF before my Laszlo application even considers loading
> them.  My understanding is that the servlet transcodes the jpeg to SWF
> before loading into the Laszlo app anyways, so would I be saving some
> time/energy by generating SWF versions of the JPEG prior?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Max Carlson | 1 Feb 2005 08:19

Re: Re: [Laszlo-user] Splash tag and image scaling bug

Hey Jon,

One reason we never noticed this is because we have always used vector 
art for the splash screens.  One possible workaround is to use vector 
art and/or convert your splash screen bitmaps to .swf manually.  You 
might also try making your splash screen smaller than the rest of the app...

Regards,
Max Carlson
Laszlo Studios

Eric Bloch wrote:
> Hey Jon,
> 
> Thanks much for the test case.
> 
> This looks like a long-standing bug.  I see it in 2.1, 2.2, and 3.0b1. \
> 
> It feels like either "an off by one" kind of bug or, I'm guessing more 
> likely, that there's some additional "scaling up and scaling down" based 
> on the existence of the preloader that's resulting in a poor scale. Adam 
> and/or Max could chime in here or anyone familiar with the LFC 
> implementation of a view's "stretches" attribute for the Flash runtime.
> 
> I don't see a workaround (yet).
> 
> -Eric
> 
> 
> Jon Gilkison wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Bloch | 1 Feb 2005 19:17

Re: Re: [Laszlo-user] Splash tag and image scaling bug

Max,

Could you file a bug on this please?

-Eric

Max Carlson wrote:
> Hey Jon,
> 
> One reason we never noticed this is because we have always used vector 
> art for the splash screens.  One possible workaround is to use vector 
> art and/or convert your splash screen bitmaps to .swf manually.  You 
> might also try making your splash screen smaller than the rest of the 
> app...
> 
> Regards,
> Max Carlson
> Laszlo Studios
> 
> Eric Bloch wrote:
> 
>> Hey Jon,
>>
>> Thanks much for the test case.
>>
>> This looks like a long-standing bug.  I see it in 2.1, 2.2, and 3.0b1. \
>>
>> It feels like either "an off by one" kind of bug or, I'm guessing more 
>> likely, that there's some additional "scaling up and scaling down" 
>> based on the existence of the preloader that's resulting in a poor
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Bloch | 1 Feb 2005 19:18

Re: Performance Optimizations ...


>> I was wondering if it'd be in my best interests to convert those
>> jpeg's to SWF before my Laszlo application even considers loading
>> them.  My understanding is that the servlet transcodes the jpeg to SWF
>> before loading into the Laszlo app anyways, so would I be saving some
>> time/energy by generating SWF versions of the JPEG prior?
>>

Btw... the conversion for non-progressive JPEGs is simply a rewrapping 
of the bits, so it's reasonably lightweight (even in java).  Progressive 
jpegs are decoded and reencoded, sadly.

-Eric
Permalink | Reply | 5 comments |
headers
Henry Minsky | 1 Feb 2005 22:07
Picon

Re: Performance Optimizations ...

Is it possible that newer (>= 6) Flash plugins can decode more flavors of JPEG? 

On Tue, 01 Feb 2005 10:18:46 -0800, Eric Bloch <bloch <at> laszlosystems.com> wrote:
> 
> 
> >> I was wondering if it'd be in my best interests to convert those
> >> jpeg's to SWF before my Laszlo application even considers loading
> >> them.  My understanding is that the servlet transcodes the jpeg to SWF
> >> before loading into the Laszlo app anyways, so would I be saving some
> >> time/energy by generating SWF versions of the JPEG prior?
> >>
> 
> 
> Btw... the conversion for non-progressive JPEGs is simply a rewrapping
> of the bits, so it's reasonably lightweight (even in java).  Progressive
> jpegs are decoded and reencoded, sadly.
> 
> -Eric
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
Permalink | Reply | 4 comments |
headers
cort | 1 Feb 2005 23:17

Re: Performance Optimizations ...

Not progressive jpg, they added it and gif support to Central but not to
the normal player.

If you look at the video part of the fileformat document they mention some
sort of sequenced gzip compressed jpg's (sounds like mjpg) that they use
for realtime video capture and display from webcams, but I think that that
is it.

> Is it possible that newer (>= 6) Flash plugins can decode more flavors of
> JPEG?
>
>
> On Tue, 01 Feb 2005 10:18:46 -0800, Eric Bloch <bloch <at> laszlosystems.com>
> wrote:
>>
>>
>> >> I was wondering if it'd be in my best interests to convert those
>> >> jpeg's to SWF before my Laszlo application even considers loading
>> >> them.  My understanding is that the servlet transcodes the jpeg to
>> SWF
>> >> before loading into the Laszlo app anyways, so would I be saving some
>> >> time/energy by generating SWF versions of the JPEG prior?
>> >>
>>
>>
>> Btw... the conversion for non-progressive JPEGs is simply a rewrapping
>> of the bits, so it's reasonably lightweight (even in java).  Progressive
>> jpegs are decoded and reencoded, sadly.
>>
>> -Eric
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Bloch | 2 Feb 2005 08:04

diagrams on wiki?

I was thinking of uploading a few diagrams that Sarah drew for the
serverless feature.

Should we enable uploads for this?

-Eric
Permalink | Reply | 1 comment |
headers
Eric Bloch | 2 Feb 2005 09:23

Re: Performance Optimizations ...

Henry,

This would be nooz to me.

-Eric

Henry Minsky wrote:

> Is it possible that newer (>= 6) Flash plugins can decode more flavors of JPEG? 
>
Permalink | Reply | 0 comments |
headers
Oliver Steele | 2 Feb 2005 12:27

Re: diagrams on wiki?

On Feb 2, 2005, at 2:04 AM, Eric Bloch wrote:

> I was thinking of uploading a few diagrams that Sarah drew for the
> serverless feature.
>
> Should we enable uploads for this?

Yes.
Permalink | Reply | 0 comments |
headers
Chris Lyman | 2 Feb 2005 15:36

RE: [Laszlo-user] Re: [Dev] Restructuring the Laszlo Documentation

Hi All,

	Sorry I'm late to this one, I've been ill the last couple of
days (my daughter swears I have a case of cooties).  Anywho, what I'd
like to see is something like Wiki meets Livedocs.  The Confluence
product supports the creation of PDF from a Wiki page, and I'd imagine
there's some way to create a tree of PDFs (or a single PDF with multiple
pages) from the hierarchy of the Wiki.

	So, in my dream world (and maybe this is the Nyquil talking) I'd
like a Wiki with that allows for protected portions of pages, and those
protected portions were the responsibility of a certain person or
persons.  To peel off a PDF we'd just instruct the Wiki to do its thing.
We would have to be disciplined on releasing new versions of pages so we
don't have a million and one versions of the manual floating around.
BUT, at the same time I'd imagine we could also maintain a bleeding edge
version of the docs for the early adopters.  In the terms of the
Confluence I believe that we'd maintain a 'space' for the current
version and then maintain a separate space for the next version.  The
current version could be frozen with the exception of adding or editing
comments, while the bleeding edge version would be open to editing until
it was released.

	All of this is taken with Olivers' point about the live examples
not working, but what do they expect?  :)

<mmmmm....that's good Nyquil>,
Chris

-----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |

Gmane