This is now fixed in trunk, and should be part of 4.7. You'll get a
warning when trying to use a drawview that's too large, rather than a
hard exception, which can halt the app.
Regards,
Max Carlson
OpenLaszlo.org
On 1/11/10 3:18 PM, Chris Kohlhardt wrote:
I was able to come up with a simple test case, and I've attached it to
http://jira.openlaszlo.org/jira/browse/LPP-8697
I hope this helps!
-chris
On Mon, Jan 11, 2010 at 11:18 AM, Chris Kohlhardt <[email protected]
<mailto:[email protected]>> wrote:
I'll give it another shot today and see if I can come up with a test
case.
-chris
On Sat, Jan 9, 2010 at 5:23 PM, Max Carlson <[email protected]
<mailto:[email protected]>> wrote:
If there's any way you can provide us with a testcase, that
would help enormously. I'd be happy to take a copy of the app,
in confidence of course - I promise to nuke it as soon as I can
derive a testcase!
I'm hoping LZOs will be fully working in swf9/10 soon - then you
could send us a binary library... Thanks!
Regards,
Max Carlson
OpenLaszlo.org
On 1/8/10 5:15 PM, Chris Kohlhardt wrote:
http://jira.openlaszlo.org/jira/browse/LPP-8697
On Fri, Jan 8, 2010 at 4:59 PM, Max Carlson
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Chris,
Any chance you could file a bug at
http://jira.openlaszlo.org/ and
attach the screenshots/testcase there? If there's a
regression in
swf9, we really want to take care of it!
Regards,
Max Carlson
OpenLaszlo.org
On 1/8/10 4:19 PM, Chris Kohlhardt wrote:
The following message bounced when I tried to send
screenshots
of the
problem.
On Fri, Jan 8, 2010 at 4:17 PM, Chris Kohlhardt
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
I compiled our using the nightly LPS build, and
this results
in our
application looking very jumbled. SWF9 and
SWF10 both show
the same
issue.
If I turn the debugger on, the application looks
correct.
(screenshots attached)
It sort of looks like constraints aren't working
as expected....
but I don't have any evidence besides visual
evidence to
prove this.
I spent some time trying to isolate the issue,
but haven't
had any
luck so far. Our application is pretty
complicated, so
it's pretty
tough to isolate issues.
Any ideas?
-chris
On Fri, Jan 8, 2010 at 3:43 PM, Henry Minsky
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>
wrote:
Did you mean the issue is that your code
(which you've been
running in swf9) compiled for swf10 has some
artifacts,
or that
compiling to swf9 in the nightly build has
problems?
On Fri, Jan 8, 2010 at 5:34 PM, Chris Kohlhardt
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
I just gave the nightly build a quick
spin, and
immediately
ran into rendering issues which I assume
are related to
SWF9.... Is SWF9 support going away?
We have decided not to adopt SWF10 yet
because we have
customers who are in the 'Enterprise'
and the data
we have
suggests Flash 10 adoption is still far
less than
90% there.
I think the Adobe numbers are misleading
(http://www.adobe.com/products/player_census/flashplayer/enterprise_penetration.html)
and the analytics on our web site
suggest Flash 10
has maybe
80% penetration.
-chris
On Fri, Jan 8, 2010 at 11:04 AM, Henry
Minsky
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>
wrote:
We just made some changes to
significantly
reduce the
RAM required for SWF9/10 compiles.
You can try
them out in
a nightly build, and tell us if you
see any
improvement
(or any new bugs, god forbid)
regarding the 'incremental compile'
option, If you
compile from the command line, the
incremental
option
will be useless right now, since the
cache it stores is in RAM. If run on
the server,
I don't
know if it makes any difference
either, it's really
just a placeholder feature now and
does not have an
efficient implementation, it
requires more work
to be
optimized to make much difference.
On Fri, Nov 20, 2009 at 4:39 PM,
Chris Kohlhardt
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
After a good amount of work,
we've managed
to get
our application completely
migrated to
OL4.6.1 and
SWF9.
Thank you very much to everyone
involved in
making
the SWF9 runtime a reality. The
performance of
Gliffy is so much faster now,
it's almost
unbelievable. We're entering QA
next week,
and we
expect to release SWF9 Gliffy in
mid December.
One thing we noticed is that
compilation of
SWF9 is
a lot slower. After some
digging, we were
able to
speed things up by:
- setting
compiler.swf9.incremental=true in
lps.properties
- allocating at least 2GB of
memory to the
tomcat
instance running the lps
- moving developers to a pure
64bit OS
(Clint moved
to Windows 7 after a long stint
with XP)
Are there any other performance
tips to
consider?
thx!
-chris
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
