Suggestions about the new ability to draw directly an icon:
What about a way to get/draw the original icon? (keep reading)
In my shine icons test (https://plus.google.com/105066926163073195690/posts/iUdNtvtcfcp) I’m drawing an effect above the current icon. The new imageScript feature is perfect for drawing custom icons without extra bitmaps, but it is also perfect for making effect to current icons. The issue is that I need to get the original icon (CustomIcon or OriginalIcon if the custom is null) and in that test I’m keeping a reference of that bitmap, which I’m sure is inefficient. Is getting the icon each time better or even worse?
Anyway I want to suggest three different ways to handle this:
#1: an ImageScript.DrawingContext#drawOriginal() function which will draw the corresponding icon with the colorize color, reflection and all that, so the image script can draw before and after it.
#2: an ImageScript.DrawingContext#getOriginalBitmap() which will return the bitmap that should have been drawed (what the previous suggestion will directly draw, but now returned as a bitmap)
I thing this is not a good suggestion, the extra bitmap is what we want to avoid.
#3: two more functions in the ImageScripts objects: drawAfter and drawBefore that will be the same as draw but one before it and the other after. The difference is that if there is no draw function, the original icon (as I described before) will be draw instead. This allow to: the current ‘override the drawing'( only a draw function) and what I want to make effects in the original icon (drawAfter and/or drawBefore, but no draw).
]]>
D5 Creation
< ![CDATA[
Keeping a reference on the bitmap is not necessarily inefficient: the launcher would have to retain this reference anyway. In the end it doesn’t really matter if it is retained by the app code or by the script code. When the script set a custom image, it replaces the current one. Hence the “internal” reference is released, and the new one (referenced by the script engine) takes its place. If the bitmap is loaded only from time to time (container load event for instance) then this won’t be a problem performance wise.
There’s some overhead if the launcher loads an image and the script reloads it through getDefaultIcon/getCustomIcon. The bitmap is loaded twice for the same item. This is because the base image is read, then transformed into a “live” one. The base image is then released. Calling getDefaultIcon/getCustomIcon always reloads it from file. Loading an image twice could be avoided by deleting both default and custom icons, and using a custom file (unknown from the launcher).
Calling getImage however returns the current in memory bitmap. This is a copy, but this is nevertheless fast when compared to file decoding.
Reagarding #1 or #2: internally there is a method responsible for compositing the base image into a final image, it could be made public. An intermediate bitmap is required because computations are possibly very expensive and cannot be made on each draw. Also input images need to be rescaled 99% of the time.
#3 is a different thing I think, this is a filter, and the app has to take care of this filter in addition to the image itself. This is an interesting suggestion, but maybe not as easy to implement as it seems at first.
]]>