Bug 40394 - Provide implementation of Icon interface in swing package
Provide implementation of Icon interface in swing package
Status: NEEDINFO
Product: Batik - Now in Jira
Classification: Unclassified
Component: (RFE) Request For Extension
1.6
Other other
: P1 normal
: ---
Assigned To: Batik Developer's Mailing list
:
Depends on: 46434
Blocks:
  Show dependency tree
 
Reported: 2006-09-01 16:57 UTC by Kirill Grouchnikov
Modified: 2009-10-27 16:56 UTC (History)
1 user (show)



Attachments
Extension for the Batik icon with resizability and asynchronous load (10.54 KB, text/plain)
2006-09-03 23:44 UTC, Kirill Grouchnikov
Details
New implementation with support for thread pool (10.86 KB, text/plain)
2006-09-05 05:47 UTC, Kirill Grouchnikov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Grouchnikov 2006-09-01 16:57:44 UTC
The org.apache.batik.swing.svg provides Swing components that show SVG images.
However, there is no bundled support for the Icon interface. Since the
JGVTComponent extends the JComponent, it can't be used as a replacement for
existing Icon implementations. It doesn't have to be as "clever" as the
JGVTComponent and its extensions, but having painting / rendering transformation
support is a must.
Comment 1 Cameron McCormack 2006-09-03 07:00:54 UTC
I agree, it probably would be handy to have such a class included in the
distribution.  Here is one I wrote a while ago (which isn't very clever), in
case you have a need for one: http://mcc.id.au/2005/04/SVGIcon.java
Comment 2 Kirill Grouchnikov 2006-09-03 07:16:23 UTC
Thanks for the implementation you have provided. Is it possible to augment this
with resizability (as with the rendering transformation on the JGVTComponent)?
Comment 3 Cameron McCormack 2006-09-03 07:33:02 UTC
No doubt it is possible.  For simple scaling, you can just pass in a different
width/height to the constructor.  For more complex transformations you could
perhaps clone the document to add in a transform attribute on the root, or
subclass the transcoder classes to do the same thing as the rendering transform
on a JGVTComponent.

Contributions are welcome. :)
Comment 4 Kirill Grouchnikov 2006-09-03 18:26:57 UTC
I was thinking about simple scaling, but not wanting to create a different icon
every time. SVG Salamander's implementation of SVGIcon has the
setPreferredSize() method that scales the internal representation to the correct
size. By the way, is the attached code synchronous or asynchronous (like
JGVTComponent)?
Comment 5 Cameron McCormack 2006-09-03 22:19:42 UTC
It is synchronous.  It just uses the transcoder to generate a BufferedImage the
first time it needs to draw the icon, then uses that in subsequent draws.
Comment 6 Kirill Grouchnikov 2006-09-03 23:44:57 UTC
Created attachment 18815 [details]
Extension for the Batik icon with resizability and asynchronous load

The attached class contains the implementation of Icon interface with
asynchronous load (copied and modified from JGVTComponent) and resizability
support (in setPreferredSize())
Comment 7 Kirill Grouchnikov 2006-09-03 23:48:08 UTC
I just attached the extended version of the class that you gave earlier. It
draws heavily from the asynchronous implementation of JGVTComponent (perhaps
this code can be extracted into a common layer) + resizability support in
setPreferredSize that schedules the rendering.

In my application i've extended this icon class with another one that registers
another GVT tree renderer listener and on completion calls a method on the
containing component asking it to redraw the icon. This way, the icon is loaded
asynchronously and the containing component is notified when it should redraw
the icon.

The only thing missing here for me - a static thread pool to dispatch the load
requests on a limited number of threads to prevent out of memory exceptions.
Comment 8 Thomas Deweese 2006-09-04 23:38:03 UTC
Hi Kirill,

   Thanks for the contribution!

   It is useful as a patch in Bugzilla but it would
be ideal if you could complete an Apache Individual
Contributor License Agreement (ICLA) which would 
allow us to make this part of Batik.

   From a short review of the code, A couple of other 
things would need to be done for us to add it to the 
Batik code base:

  1) It would have to be made compilable under JDK 1.3
     (the current target for Batik).  I see that it is
     using generics. I didn't see any really deep 
     dependencies.

  2) Something a little more elegant would need to be
     done with the rendering cache.  I think it will be
     problematic to have the cache grow without bound.

  3) Also a minor nit, remove the use of '*' in import
     statements.
Comment 9 Kirill Grouchnikov 2006-09-04 23:47:00 UTC
Cameron,

Where do i find that agreement to sign ICLA (hope it's OK and will not clash
with my employer contract)? You're right about generics - i've wrote it in a 5.0
project, but the only thing there is for the image cache. I agree that it should
be bound (LinkedHashMap would be soooo great here). I need to find / write some
code to make the proper renderer thread pool. Hope it's not too complicated for 1.3.

Last thing - about those * in imports. This is how i prefer them. I just *hate*
two-three page-long import sections :) But that's just me. Feel free to hack at
that code in the meantime until i find a reasonable and robust thread pool
implementation. With any luck some other Apache project already has it...
Comment 10 Thomas Deweese 2006-09-05 00:24:21 UTC
Hi Kirill,

(In reply to comment #9)
> Where do i find that agreement to sign ICLA 

  Sorry I ment to include the link:
     http://www.apache.org/licenses/

> (hope it's OK and will not clash with my employer contract)? 

   This is exactly what the ICLA is ment to clarify, if you
can actually contribute code to an Apache Project.

> Last thing - about those * in imports. This is how i prefer them. 
> I just *hate* two-three page-long import sections :) But that's 
> just me. 

   I just hate having no clue what a file is really depending on ;)
Comment 11 Kirill Grouchnikov 2006-09-05 05:47:59 UTC
Created attachment 18819 [details]
New implementation with support for thread pool
Comment 12 Kirill Grouchnikov 2006-09-05 05:53:15 UTC
I just attached a new implementation that has support for thread pool. I've read
through the linked license and it's too much pain for me to understand / consult
at work / ... In addition, the thread pool implementation uses the new
concurrent stuff from 5.0 (Executors and ExecutorService) - i just can't justify
(for myself) to reinvent the wheel when my own project runs on 5.0. See comments
on 40393 about a possibility to depend on Apache Excalibur and their thread pool
- this is your decision if you want to provide support for this out of the box.

It's just too much hassle for me to do something that already exists in two
lines of code in JDK 5.0 by either implementing it myself / searching the web
for ASF-compliant implementation / copy-pasting stuff from Excalibur. 

The current implementation (attached) just extends your own code with stuff from
JGVTComponent + very simple support for resizing. Feel free to use it or any
other approach if you decide to implement it in the next Batik version. I just
don't feel very comfortable will that licensing / signing / lawyer-oriented
language. Sorry.
Comment 13 Helder Magalhães 2009-01-10 06:35:13 UTC
(In reply to comment #12)
> at work / ... In addition, the thread pool implementation uses the new
> concurrent stuff from 5.0 (Executors and ExecutorService) - i just can't justify
> (for myself) to reinvent the wheel when my own project runs on 5.0.

Sounds reasonable (at least, to me). Marking as dependent on dropping Java 1.4 support (bug 46434) in order for this to be able to land without much more work in the future - whenever the project leaders decide Java 1.5 is the minimum version. Of course that, as already suggested, this can probably be reworked to support Java 1.4 (minimum version in trunk, currently)...


> I just don't feel very comfortable will that
> licensing / signing / lawyer-oriented language. Sorry.

So this is it? A potentially great contribution getting lost in the bug tracker due to lack of a license agreement? I'd be pretty sad if this wasn't reverted. :-|

Note that, in order for contributions to get integrated into the framework, the ICLA signing step [1] is necessary. This is basically only to assure no legal disputes will occur and that you really contribute things without anything in exchange (please correct me if I'm wrong!). Plain text [2] and PDF [3] versions are available. Marking the issue as "need info" to call for a follow up.

Please re-consider contributing! :-)


[1] http://www.apache.org/licenses/#clas
[2] http://www.apache.org/licenses/icla.txt
[3] http://www.apache.org/licenses/icla.pdf
Comment 14 Helder Magalhães 2009-01-11 02:33:43 UTC
(In reply to comment #13)
> This is basically only to assure no legal
> disputes will occur and that you really contribute things without anything in
> exchange.

I did try to find (but wasn't able to) a human-readable/simplified version of the Apache License - Creative Commons [1], for example, have such simplified summaries - just choose a license to see what I mean (at the bottom of each license there's a footnote pointing to the legal version). If someone is in possess of such link and/or knowledge, it would be great to share in order to, possibly, add a link and/or text portion to the license page [2] to make the legal understanding process smoother. :-)

[1] http://creativecommons.org/licenses/
[2] http://xmlgraphics.apache.org/batik/license.html
Comment 15 Helder Magalhães 2009-10-27 16:56:53 UTC
(In reply to comment #14)
> I did try to find (but wasn't able to) a human-readable/simplified version of
> the Apache License

Well, recently I stumbled across a human-readable summary [1] of the full license text which, although pretty introductory, should help. ;-)


[1] http://www.codeproject.com/info/Licenses.aspx#ctl00_MC_LR_ctl08_N