[flexcoders] Chart font image quality
Hi, I am trying to add some charts to a PDF using AlivePDF. Adding the image to the PDF looks horrible (very fuzzy font). I have tried using the ImageCapture with a high dpi, which looks alot better, but there are still a lot of 'artifacts' around the text in the chart labels. I also tried to use a bitmap font from a Flash swf, but am getting the same noise around the text. Is there anyway to get the image of a chart that is good enough to print without the labels looking like this? Especially when I have 'real' text along side this chart image, the result is very disappointing. I really need a printable report that looks nice. I suppose AlivePDF has nothing to do with it really, it's more of getting a high quality image. Thanks for any suggestions...
Re: [flexcoders] Flex Builder Does Not Compile Module
In flexbuilder -- right click your project-click properties, go to 'Flex Modules' and add the module to the list. It should compile with the rest of the app now. Hope that is what you needed - Original Message - From: ilikeflex To: flexcoders@yahoogroups.com Sent: Monday, September 29, 2008 12:37 PM Subject: [flexcoders] Flex Builder Does Not Compile Module Hi I am using module to create application.I have taken sample from http://blogs.adobe.com/flexdoc/2007/01/modules_documentation_update.ht ml I have put the following files into seprate project. AutoInsurance.mxml(Is a module) IModuleInterface.as Main.mxml Now when i run Main.mxml file.AutoInsurance.mxml is not compiled and seprate AutoInsurance.swf is not generated. Though doc below says that it should happen. Is this bug. Flex Documentation says In Flex Builder, you can either run the module as if it were an application or you can build the module's project. If the modules are in the same project as your Flex application, then when you run your application, Flex Builder compiles the modules' SWF files for you. The SWF files are then loaded into the application at run time. Please let me know if there is anothe group for flex builder Thanks ilikeflex __ Information from ESET NOD32 Antivirus, version of virus signature database 3480 (20080929) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: [flexcoders] Speeding up draw time with nested VBoxes
Ya, I was joking about the grudge -- just some nice frustrated learning
experience feelings! I don't know why but I've always had the impression that
item renderers slowed down the list/datagrid display, so it's good to see
people telling me I'm wrong.
I'll do the custom renderer on my 2nd pass of finishing up this application.
With this experience I've also found that using binded x/y values
'y={something.x + something.y}' really really slows things down as well.
Changing that code I was able to get down to around 1000ms. Not what I wanted,
but more acceptable forsure!!
I can see where renderers would make the code much more managable, so it will
always be in the back of my mind as well.
I appreciate all the feedback and pointers...
Thanks much,
Jason
- Original Message -
From: Michael Schmalle
To: flexcoders@yahoogroups.com
Sent: Tuesday, September 23, 2008 6:26 PM
Subject: Re: [flexcoders] Speeding up draw time with nested VBoxes
plus I have a grudge against vboxes now :P
It's not the gun that kills but the finger that pulled the trigger... ;-)
VBoxs serve their purposes and perform great when they are used 'correctly'.
I know that sounds bad but I don't mean it like that.
There are while(loops) in the layout code that acts like a circular saw, when
it's grinding it's taking A LOT of energy from the Player, the large the wood,
the more power it needs.
The plus side is, since the algorithms are so good in it, with controls that
have limited children and layout logic, there is a lot you can do with boxes
(stretching).
But Tracy is totally right, item renderers are what you need. I think this
will change in the future, the way developers look at 'renderers'. Renderers
abstract and decouple your repetitive layout and child creation code from the
main component controller. You can then at any time in the future optimize a
renderer of any kind easily and efficiently.
Mike
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3468 (20080924) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
[flexcoders] Speeding up draw time with nested VBoxes
Hi, I have a component that extends VBox. I am making around 20 instances of this component. That component also contains a VBox, each of which contains 2-6 components. This takes a long time from creation to when I can see it on the screen -- around 3000ms. If I don't use a VBox in that 2nd component, it shaves around 700ms off the time. If I take out all my addChild's from the main component that is creating all of this (just creating the components) the total time is around 30ms. Is it the VBox that is hurting my performance by nature? And does anyone have any suggestions to speed it up? This is my first real performance problem since I started using flex. I know it's not the same, but with AS2 I could make 10X more display objects and not see this kind of performance. Any help is appreciated! Jason
Re: [flexcoders] Speeding up draw time with nested VBoxes
Thanks for the response! Yes I need Vbox functionality (unless I want to code the layout on creationComplete, which is my next idea to try -- but I'm sure to run into some caveats with resizing I think). Each component has a textfield with variable textHeight -- so things need to line up appropriately. They are pretty simple -- in the main vbox... each component has a label + textfield(2) + vbox(which contains a graphic + textfield -- again variable height). I did try taking out my html textboxes and graphics, but that did not improve performance at all -- which makes me think it really is the vbox slowing it down. Also it does indeed use scrollbars -- there is no way I can fit this on the screen without vertical scrolling. When you say replace it with a list -- does that really have the potential to perform better if the renderers need all the components mentioned above?? That would be worth trying, but just doesn't seem right. Jason - Original Message - From: Tracy Spratt To: flexcoders@yahoogroups.com Sent: Tuesday, September 23, 2008 4:00 PM Subject: RE: [flexcoders] Speeding up draw time with nested VBoxes The first question is, do you need Vbox functionality, punk? ;) If so, then you are stuck with it. If you are just using it to lay out static vertical display, then there may be other approaches. Layout containers are very easy to use, but are heavy (slow) Next thing is they way you are doing things, you are forcing the Player to render up to (20 * 6) visual objects. They must be pretty simple components, because 3 seconds is pretty good. If they were complex, you would be looking at much longer delay. Does this process produce elements that are not visible, ie scrollbars? If yes, then why would you want to render (make visible) things you can't see? The list-based controls and item renderer mechanisms are designed to minimize rendering of visual objects, which is, and has always been, the player's performance bottleneck. Consider replacing addChild and Vbox with a List and a custom item renderer. Tracy -- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Speeding up draw time with nested VBoxes Hi, I have a component that extends VBox. I am making around 20 instances of this component. That component also contains a VBox, each of which contains 2-6 components. This takes a long time from creation to when I can see it on the screen -- around 3000ms. If I don't use a VBox in that 2nd component, it shaves around 700ms off the time. If I take out all my addChild's from the main component that is creating all of this (just creating the components) the total time is around 30ms. Is it the VBox that is hurting my performance by nature? And does anyone have any suggestions to speed it up? This is my first real performance problem since I started using flex. I know it's not the same, but with AS2 I could make 10X more display objects and not see this kind of performance. Any help is appreciated! Jason __ Information from ESET NOD32 Antivirus, version of virus signature database 3466 (20080923) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: [flexcoders] Speeding up draw time with nested VBoxes
Thanks much for the insight! I have not been following the item renderer posts, but I'll have to take a gander. Mostly what I've used renderers for is just using a component as a column in a datagrid -- or making a checkbox list extended from the list component. If I'm going to do this -- I'll go all the way -- plus I have a grudge against vboxes now :P -- so I'll check out ListItemRenderer, I don't know off the top of my head how exactly I'm starting here. Using a list component that uses the custom ListItemRenderer instead of the built in one? I'll figure it out. Thanks again for throwing me in a better direction so quickly! - Original Message - From: Tracy Spratt To: flexcoders@yahoogroups.com Sent: Tuesday, September 23, 2008 4:51 PM Subject: RE: [flexcoders] Speeding up draw time with nested VBoxes Yes, Yes, Yes, a list based component will perform MUCH better than what you have. If you have been following any of the item renderer posts/answers, you will see that item renderers are tightly integrated with the Flex framework, and are optimized to minimize rendering. The visual elements are re-used, and they make heavy use of the invalidation mechanism to make sure they do only the work really required. This makes them a bit of a pain to code, but the benefit is performance in just this kind of case. Now, do NOT make the item renderer out of a Vbox. You will get noticable benefit from the recycling, but not the most. Instead, make your renderer out of UIComponent. To do this is kind complicated. Copy the ListItemRenderer.as code and start with it as your base and modify it as needed. Look especially at the measure() code. That is what you will use to deal with your variable height subcomponents. It is not trivial, but certainly reasonable. Ok, if you want to do this in steps, to make sure you are getting some benefit, go ahead and make your renderer out of a Vbox, but remember it is only going to give you part of the performance gain. Commit to making the UIComponent the next stage. Tracy -- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 5:18 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Speeding up draw time with nested VBoxes Thanks for the response! Yes I need Vbox functionality (unless I want to code the layout on creationComplete, which is my next idea to try -- but I'm sure to run into some caveats with resizing I think). Each component has a textfield with variable textHeight -- so things need to line up appropriately. They are pretty simple -- in the main vbox... each component has a label + textfield(2) + vbox(which contains a graphic + textfield -- again variable height). I did try taking out my html textboxes and graphics, but that did not improve performance at all -- which makes me think it really is the vbox slowing it down. Also it does indeed use scrollbars -- there is no way I can fit this on the screen without vertical scrolling. When you say replace it with a list -- does that really have the potential to perform better if the renderers need all the components mentioned above?? That would be worth trying, but just doesn't seem right. Jason - Original Message - From: Tracy Spratt To: flexcoders@yahoogroups.com Sent: Tuesday, September 23, 2008 4:00 PM Subject: RE: [flexcoders] Speeding up draw time with nested VBoxes The first question is, do you need Vbox functionality, punk? ;) If so, then you are stuck with it. If you are just using it to lay out static vertical display, then there may be other approaches. Layout containers are very easy to use, but are heavy (slow) Next thing is they way you are doing things, you are forcing the Player to render up to (20 * 6) visual objects. They must be pretty simple components, because 3 seconds is pretty good. If they were complex, you would be looking at much longer delay. Does this process produce elements that are not visible, ie scrollbars? If yes, then why would you want to render (make visible) things you can't see? The list-based controls and item renderer mechanisms are designed to minimize rendering of visual objects, which is, and has always been, the player's performance bottleneck. Consider replacing addChild and Vbox with a List and a custom item renderer. Tracy From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Reynolds Sent: Tuesday, September 23, 2008 4:32 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Speeding up draw time with nested VBoxes Hi, I have a component that extends VBox. I am making around 20 instances
Re: [flexcoders] AMFPHP and date/datetime data from MySQL
Adobe has some date parsing methods in the as3corelib library -- http://code.google.com/p/as3corelib/ I suppose it depends on the format your storing the date, the way I've been handling it is using as3 to parse the date string that AMF returns. Not sure if this is the best way, I'd be open to a better one! Hope that helps, I can attempt to help more if it doesn't. I've been using AMFPHP for awhile now... would be nice to make any contacts that use it! - Original Message - From: Nik Derewianka To: flexcoders@yahoogroups.com Sent: Wednesday, September 03, 2008 6:00 AM Subject: [flexcoders] AMFPHP and date/datetime data from MySQL Hi All, Could anyone enlighten me as to how i should send and retrieve date and datetime data for inserting into MySQL via amfphp (1.9) with value objects ? If i edit the data directly in MySQL and then retrieve a vo with a Date datatype i get the following message: TypeError: Error #1034: Type Coercion failed: cannot convert 1970-01-01 to Date. So, I need to format the date in someway so that flex can deserialize it properly. Any insight would be greatly appreciated (am coming from .net land so new to both PHP and as3). Cheers, Nik __ Information from ESET NOD32 Antivirus, version of virus signature database 3411 (20080903) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
