|
Replies:
75
-
Last Post:
Nov 7, 2006 2:34 PM
by: Scott Violet
|
|
|
|
|
|
|
JXPanel and Translucency
Posted:
Aug 25, 2006 1:15 PM
|
|
|
We had an internal review today that covered the JXPanel and ran into some issues with regards to translucency.
Currently, there is an "alpha" property on the JXPanel which you can use to specify how translucent the panel and its contents should be. The "paint" method of JXPanel sets an AlphaComposite on the Graphics used for painting, causing JXPanel and all components on it to be translucent.
However, what happens if a child component is painted? Normally, that paint request only goes up the tree if the child component is not opaque, otherwise only the child component is painted. However, since JXPanel needs to set the AlphaComposite, it is necessary that painting start at the JXPanel, not at the child component.
The current solution is to install a custom repaint manager. The repaint manager walks up the containment heirarchy looking for a JXPanel that is translucent. If there is one, painting starts from there.
The obvious problem with this hack is that we replace the repaint manager (behind the scenes!). Eek.
There is another solution. If I had a visible, non-opaque, fully transparent component on top of all the components on the JXPanel (think: glasspane), then painting is forced to happen starting from the JXPanel (remember: walk up the tree if non-opaque. And, since the component covers the whole area, it causes painting to start at the top -- the JXPanel the "glasspane" is covering).
For this solution to work, the JXPanel would need to have a JLayeredPane within it. That layered pane would have a content pane and a transparent visible helper pane. Just like with JFrame, we could automatically route add/remove calls to the content pane. So, API wise, you'd still use it the same as before.
Almost.
The problem is that now, in any code walking the containment heirarchy, you will be 2 levels removed. That is, before it was JXPanel->JTextField, but now it would be JXPanel->JLayeredPane->Content Pane->JTextField.
For this reason, it was proposed to split the translucency functionality out of JXPanel into JXTranslucentPanel/JXLayeredPanel which would then extend JXPanel.
What do y'all think of this?
There is an additional benefit for having a JXLayeredPanel --> you could use it to achieve mini glass pane effects. That is, instead of having to use the frame level glass pane and translate to a per component basis, you could paint on the component itself. For some effects, this could be nice.
Richard
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Aug 25, 2006 4:31 PM
in response to: rbair
|
|
|
What does a "mini-" JXLayeredPane buy you that you don't get with the existing JLayeredPane? Or is it just a solution in search of more raison d'etre?
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Aug 28, 2006 9:05 AM
in response to: twalljava
|
|
|
> What does a "mini-" JXLayeredPane buy you that you
> don't get with the existing JLayeredPane? Or is it
> just a solution in search of more raison d'etre?
Do you mean "JXLayeredPanel" as opposed to JXLayeredPane? I appologize for using that term, think JXTranslucentPanel instead.
I'm not sure I understand your question, so I'll try to recap perhaps more clearly what I intend.
We want to have a simple property on a panel that will cause all components within that panel to be translucent.
To achieve this outside Swing core is a hack -- no way around that. It doesn't have to be a nasty hack, but it will be a hack.
The problem is that for this to work, we alter the composite on the Graphics object in the JXPanel to be an AlphaComposite. Thus, for all child components to be translucent, the "paint" method of the JXPanel must be called.
This is not always the case for performance reasons. Normally we only repaint those components that we need to repaint. For example, a JCheckBox on a JXPanel may be where the repaint occurs, rather than the JXPanel. This would cause the JCheckBox to be rendererd fully opaque instead of translucent, because the JXPanel never got a chance to set the AlphaComposite on the Graphics object.
Two solutions we have found so far: first, install a custom repaint manager; second, use a JLayeredPane, put the child components into a content pane on the layered pane and then make a "glass pane" visible and non-opaque. This forces the RepaintManager to paint all the components over which the "glasspane" is layered (I use "glasspane" in quotes because it is _a_ glass pane, but not _the_ glass pane).
The first solution is deemed "bad" because the JXPanel was installing this custom RepaintManager behind the scenes. Whoa! The second solution isn't perfect either, but at least it can do it's job without side effects on other code. (the other solution, use the custom RepaintManager but force the developer to install it, is undesireable because of the extra step and mental complexity. In addition, if folks have a custom repaint manager already then installing a custom repaint manager would be clearly be a problem).
Since we would have a JLayeredPane within a JXTranslucentPanel/JXLayeredPanel (whatever you want to call it), it could be reused as a "mini" glass pane. There have been times when working with Romain when we've wanted such a thing for certain effects. The primary reason we'd have a JXTranslucentPanel would be for the translucency.
Richard
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Aug 28, 2006 9:31 AM
in response to: rbair
|
|
|
+1 on a separate JXTranslucentPanel/JXLayeredPanel class. I could really use a mini-glass pane for our current project.
Erik
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 19, 2006 7:11 AM
in response to: evickroy
|
|
|
I know this thread is getting old but I have run into a few problems while trying to implement my own translucent panel using the 'glasspane' approach.
The problem is down to the differences between initiating a paint from the translucent panel (as happens when replacing the repaint manager - i.e. the source of the repaint event is changed) and moving up the tree to find the component to paint first (as happens when using a glass pane - i.e. start from the common parent of obscured components).
To illustrate the problem take the following component tree:
JRootPane (opaque)
JLayeredPane (not opaque)
JTranslucentPanel (not opaque optimizedDrawing disabled)
JComponent (not opaque glass pane)
JComponent (not opaque content pane)
JButton (opaque)
Say the button calls repaint, with the repaint manager approach this will call the addDirtyRegion on a custom RepaintManager which traverses the tree until it gets to JTranslucentPanel at which point it registers the dirty region as originating from the JTranslucentPanel parent. When the refresh occurs paintImmediately is called on JTranslucentPanel which in turn traverses the component tree until it finds a parent which is opaque (the JRootPane) whose internal _paintImmediately method is called which results in that components paint method being called, painting all its children as needed. All works as expected.
Contrast that with the glasspane approach.
The button calls repaint and the standard RepaintManager registers the dirty region as originating from the JButton. When the refresh is called the buttons paintImmediately is called and as it is opaque calls its own _paintImmediately method. This method traverses the component tree to find the parent which should originate the painting. This involves checking the isOptimizedDrawingEnabled property of all parents until it find one that returns false and has children which overlap the JButton. The only component which does this is JTranslucentPanel. Once found that components paint method is called painting its children as needed.
We now have the problem that painting is originating from a non-opaque component which gives odd buffer problems which you will see if you set a component to opaque but override its paint method so that it does nothing.
I guess my question is, what sort of progress has been made regarding the JXTranslucentPanel and have you managed to overcome the problems I'm having with mine?
Thanks in advance.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 19, 2006 10:20 AM
in response to: mattnathan
|
|
|
> I guess my question is, what sort of progress has
> been made regarding the JXTranslucentPanel and have
> you managed to overcome the problems I'm having with
> mine?
Not a lot -- been hung up on other issues. Very good posting though, thanks for that! The last I had talked with Scott I believe it was decided that the custom repaint manager was really the lesser of two evils.
Richard
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 19, 2006 12:05 PM
in response to: rbair
|
|
|
jdnc-interest@javadesktop.org wrote:
>> I guess my question is, what sort of progress has
>> been made regarding the JXTranslucentPanel and have
>> you managed to overcome the problems I'm having with
>> mine?
>
> Not a lot -- been hung up on other issues. Very good posting though,
> thanks for that! The last I had talked with Scott I believe it was
> decided that the custom repaint manager was really the lesser of two evils.
Yep. For the reasons mentioned by Matt, and a couple of others, the
GlassPane approach just doesn't work well for this task.
-Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 20, 2006 1:25 AM
in response to: Scott Violet
|
|
|
Thanks for the confirmation I can stop banging my head on my desk now  .
As a result of this problem I have been working on a generic RepaintManager extension API for use in this case and others (namely a MirrorPanel that I've been having trouble with). Unfortunately I have developed this as part of a company project so cant post/commit the code just yet (will try to convince my boss to let me, otherwise will redevelop in my own time).
A general description of how the API works is as follows.
Define an interface which is able to adjust the properties of the addDirtyRegion method in RepaintManager (something like JComponent extendDirtyRegion(JComponent original, Rectangle dirtyRegion)) which components can implement if they require changes to this behavior. When addDirtyRegion is called the extended RepaintManager goes up the component tree to find classes who implement this interface. If found the extension methods are called adjusting the repaint region and source component. Once the root has been reached the default RepaintManager's addDirtyRegion method is called with the new dirty region and source component.
If done properly all you need to do to get painting to start at your translucent panel is implement RMExtension (or whatever its called) with:
public JComponent extendDirtyRegion(JComponent original, Rectangle dirtyRegion) {
return this;
}
and install the new RepaintManager.
This approach lets you do all sorts of amazing effects with ease. As well as translucency you can do mirroring (like the reflecting icons in Arieth), bleeding (like the startup pearl in Vista for those who have it), stacking (that effect you get from the old superman films starting credits ;)), or whatever you want. Each of these effects will update in real-time as child components are repainted (i.e. showing the blinking caret in a text box, the indeterminate part of a progress bar, button rollover effects, etc) and can give some very interesting UIs.
I will work hard to get this code released but you should have enough information here to be able to implement your own if you can't wait .
Hope this helps and please post any comments or questions you have (or if this has already been implemented elsewhere).
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 20, 2006 9:08 AM
in response to: mattnathan
|
|
|
Sounds very interesting! I'll make sure this is seen by Scott when he gets back from vacation. He's the expert when it comes to painting in Swing.
Richard
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 21, 2006 7:42 AM
in response to: rbair
|
|
|
Thanks, can't wait to hear what he thinks.
In the meantime I find myself at home and bored so have rustled up the implementation of the RepaintManager that I mentioned above.
Sample:
http://indomus.co.uk/java/examples/TranslucentPanel.jnlp
Source:
http://indomus.co.uk/java/examples/TranslucentPanel.zip
The Web Start app is a simple use of the RepaintManager to provide the translucency you find in JXPanel, use the slider to adjust the translucency of the other components (sorry the sample isn't more spectacular but I wrote it on my laptop and I'm sure I'm not the only one who finds it frustrating to code with such small keys).
Note that this code is just for demonstration purposes and hasn't been tested other than to see if it runs and works.
Any feedback is most welcome.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 21, 2006 7:50 AM
in response to: mattnathan
|
|
|
I love this new implementation. Very clean, very concise!
I have been thinking about a ReflectionPanel for quite some time now and I'm ready to roll out some helper classes that help writing such effects. Could you explain me how I could use your repaint manager to automatically generate reflections of any component?
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 4:18 AM
in response to: gfx
|
|
|
Thanks for that, please feel free to use it/extend it as you like.
> Could you explain me how I could use your
> repaint manager to automatically generate
> reflections of any component?
Say you have a class MirrorPanel which, on top of the code for painting the standard component and reflection, also has the method Rectangle getReflectedBounds(Rectangle source) which converts bounds in the standard view to bounds in the reflection all you would have to do would be to implement RepaintManagerExtension with the following:
public boolean extendDirtyRegion(JComponent original, Rectangle region) {
region.setBounds(region.createUnion(getReflectedBounds(region)));
return true;
}
(there's probably a better way to do this without using so many temporary Rectangles but for demonstration purposes it will do)
The last step is to call ExtensionRepaintManager.install() and your done. The repaint manager will now extend the dirty region to include the reflection of the dirty region allowing your code to update it when needed.
Hope this helps.
Matt
PS. The way I implemented the reflection at work is to externalise the reflection code into my own version of the standard swingx Effect interface. This version has the additional method Rectangle getEffectBounds(Rectangle sourceBounds) which is a generic equivalent to getReflectedBounds mentioned above. This allows me (if I get time) to implement a reflection effect which mirrors the component like it was over water (with ripples etc) as well as in the standard (upside-down + fade) way. My getReflectedBounds method uses this to convert the bounds adding a gap between the reflection and the component when requested.
PPS. My personal preference would be to call it MirrorPanel instead of ReflectionPanel due to the ambiguity with java reflection.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 5:31 AM
in response to: mattnathan
|
|
|
Thanks for the information, I'll try to implement something. Since I just added a ReflectionRenderer in SwingX, it should be very easy to do.
P.S: My problem with the name MirrorPanel is that it makes me think of a perfect reflection, with no fade at all.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 5:58 AM
in response to: gfx
|
|
|
No problem, I'll be looking forward to a sufficiently bells-and-whistles enabled demo in the near future 
Matt
PS. Your blog on the graphics utilities you mention reminds me that, depending on the implementation, the shadow panel used in the Shadow demo may benefit from this RepaintManager too especially when the shadow is offset or transparent children are used.
PPS. Fair point on the name, especially if everything else refers to it as reflection.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 6:09 AM
in response to: mattnathan
|
|
|
My DropShadowPanel definitely sucks. I just recreate a picture of the content everytime a property is changed, so the performance are quite bad (compared to the ShadowRenderer which works really fast.) If you have the time to look into it and write a new panel with your repaint manager that could handle that, it'd be great
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 6:24 AM
in response to: gfx
|
|
|
I'll look into it, just need to find a spare keyboard so I don't have to use my laptop one.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 6:30 AM
in response to: mattnathan
|
|
|
I do code on laptops all the time ^^
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 6:35 AM
in response to: gfx
|
|
|
Ah well I've got an Acer Aspire 9500 which has extra small r-shift, '.,', '/?' and enter and no single key home/end keys. It's like they looked at what keys a developer uses the most and made them small
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 10:52 AM
in response to: mattnathan
|
|
|
Just finished a very (very) crude version of the ShadowPanel, there's no optimisation to do with painting only the bit of the shadow that needs painting and the demo is a bit plain but it works and here it is:
Demo:
http://indomus.co.uk/java/examples/ShadowPanel.jnlp
Source:
http://indomus.co.uk/java/examples/ShadowPanel.zip
The three controls at the bottom are distance, angle and size in that order.
I'll get around to implementing a better demo at some point later in the week as well as trying to get the rendering to be a bit more performant.
The shadowing is performed by the new ShadowRenderer added by Romain to SwingX.
Comments welcome.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 11:01 AM
in response to: mattnathan
|
|
|
Wow, performance are much better than with my DropShadowPanel
implementation.
Note that you can simply use
GraphicsUtilities.createTranslucentCompatibleImage() to create your
buffer.
On 22 oct. 06, at 19:52, jdnc-interest@javadesktop.org wrote:
> Just finished a very (very) crude version of the ShadowPanel,
> there's no optimisation to do with painting only the bit of the
> shadow that needs painting and the demo is a bit plain but it works
> and here it is:
>
> Demo:
> http://indomus.co.uk/java/examples/ShadowPanel.jnlp
> Source:
> http://indomus.co.uk/java/examples/ShadowPanel.zip
>
> The three controls at the bottom are distance, angle and size in
> that order.
>
> I'll get around to implementing a better demo at some point later
> in the week as well as trying to get the rendering to be a bit more
> performant.
>
> The shadowing is performed by the new ShadowRenderer added by
> Romain to SwingX.
>
> Comments welcome.
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=165650
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 22, 2006 12:09 PM
in response to: Romain GUY
|
|
|
> Wow, performance are much better than with my
> DropShadowPanel
> implementation.
I'm still not happy with it, especially at large resolutions (like when maximised) but I'm almost convinced that there's a way to reduce the area that gets shadowed by making it clip aware.
> Note that you can simply use
> GraphicsUtilities.createTranslucentCompatibleImage()
> to create your
> buffer.
I'll do just that when I add the above performance improvements and tidy up the code.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 8:50 AM
in response to: mattnathan
|
|
|
By the way, I just changed the behavior of ShadowRenderer. It now returns an image larger than the original, so there's no need to add the extra margins yourself if you want to avoid the shadow to be clipped.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 9:37 AM
in response to: gfx
|
|
|
> By the way, I just changed the behavior of
> ShadowRenderer. It now returns an image larger than
> the original, so there's no need to add the extra
> margins yourself if you want to avoid the shadow to
> be clipped.
I was wondering about that . Will look at my code when I get home and see what needs to change.
I stared discussion with my boss today about open-sourcing some of my work here, seeing as SwingLabs and SwingX have both been very influential in what I've implemented. Unfortunately the nature of these things tends to be slow. Anyway if your interested the things that I will be committing first include:
- ScalePolicy: Utility class for fitting a dimension inside another one (your createThumbnail methods would benefit from this Romain). This provides flags for scaling one or both dimensions, either growing, shrinking or both resizes and fixed/non-fixed ratios.
- LocationPolicy: Similar to above but for locating a dimension within another. Currently only compass points but extensible enough to provide any location policy (i.e. CSSLocationPolicy etc). Useful for positioning icons and centering.
- ReflectionPanel: Yes I have one of these too. Its more code than I'm eager to replicate.
- TranslucentPanel: beefed up version of what I released before.
- Advanced Icons API: Includes ScalableIcons, CompoundIcon (Overlay, Stack and Pile), ReflectionIcon, MatteIcon, TempIcon + support for async image loading in icons. Includes an IconPanel for scaling icons easily.
- Painters: Some extra painters.
- MultiSizeList: JList extension which provides a HUGE amount of flexibility for _WRAP orientations including non-grid behavior, stretching and row/column-based sizing.
- MultiSizeListEditor: Visual editor which overlays the above component providing handles and controls for resizing/manipulating the context areas.
- Layouts: Various new layouts and extensions to the built in ones.
- Anything else I can get away with
As I said above this could take a while to filter through the management/decision makers but I will let you know if/when it happens. If there's anything there that particularly interests anyone let me know and I'll focus more on that (or release a personal version like I did with the ExtensionRepaintManager if the code isn't too big).
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 9:50 AM
in response to: mattnathan
|
|
|
I can't wait for the ReflectionPanel
On 23 oct. 06, at 18:37, jdnc-interest@javadesktop.org wrote:
>> By the way, I just changed the behavior of
>> ShadowRenderer. It now returns an image larger than
>> the original, so there's no need to add the extra
>> margins yourself if you want to avoid the shadow to
>> be clipped.
>
> I was wondering about that . Will look at my code when I get home
> and see what needs to change.
>
> I stared discussion with my boss today about open-sourcing some of
> my work here, seeing as SwingLabs and SwingX have both been very
> influential in what I've implemented. Unfortunately the nature of
> these things tends to be slow. Anyway if your interested the things
> that I will be committing first include:
>
> - ScalePolicy: Utility class for fitting a dimension inside
> another one (your createThumbnail methods would benefit from this
> Romain). This provides flags for scaling one or both dimensions,
> either growing, shrinking or both resizes and fixed/non-fixed ratios.
> - LocationPolicy: Similar to above but for locating a
> dimension within another. Currently only compass points but
> extensible enough to provide any location policy (i.e.
> CSSLocationPolicy etc). Useful for positioning icons and centering.
> - ReflectionPanel: Yes I have one of these too. Its more
> code than I'm eager to replicate.
> - TranslucentPanel: beefed up version of what I released
> before.
> - Advanced Icons API: Includes ScalableIcons, CompoundIcon
> (Overlay, Stack and Pile), ReflectionIcon, MatteIcon, TempIcon +
> support for async image loading in icons. Includes an IconPanel for
> scaling icons easily.
> - Painters: Some extra painters.
> - MultiSizeList: JList extension which provides a HUGE
> amount of flexibility for _WRAP orientations including non-grid
> behavior, stretching and row/column-based sizing.
> - MultiSizeListEditor: Visual editor which overlays the
> above component providing handles and controls for resizing/
> manipulating the context areas.
> - Layouts: Various new layouts and extensions to the built
> in ones.
> - Anything else I can get away with
>
> As I said above this could take a while to filter through the
> management/decision makers but I will let you know if/when it
> happens. If there's anything there that particularly interests
> anyone let me know and I'll focus more on that (or release a
> personal version like I did with the ExtensionRepaintManager if the
> code isn't too big).
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=165969
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 10:55 AM
in response to: mattnathan
|
|
|
What do your new Painters do? (The other stuff is cool too, but I've
got painters on the brain right now).
- J
On Oct 23, 2006, at 9:37 AM, jdnc-interest@javadesktop.org wrote:
>> By the way, I just changed the behavior of
>> ShadowRenderer. It now returns an image larger than
>> the original, so there's no need to add the extra
>> margins yourself if you want to avoid the shadow to
>> be clipped.
>
> I was wondering about that . Will look at my code when I get home
> and see what needs to change.
>
> I stared discussion with my boss today about open-sourcing some of
> my work here, seeing as SwingLabs and SwingX have both been very
> influential in what I've implemented. Unfortunately the nature of
> these things tends to be slow. Anyway if your interested the things
> that I will be committing first include:
>
> - ScalePolicy: Utility class for fitting a dimension inside
> another one (your createThumbnail methods would benefit from this
> Romain). This provides flags for scaling one or both dimensions,
> either growing, shrinking or both resizes and fixed/non-fixed ratios.
> - LocationPolicy: Similar to above but for locating a
> dimension within another. Currently only compass points but
> extensible enough to provide any location policy (i.e.
> CSSLocationPolicy etc). Useful for positioning icons and centering.
> - ReflectionPanel: Yes I have one of these too. Its more
> code than I'm eager to replicate.
> - TranslucentPanel: beefed up version of what I released
> before.
> - Advanced Icons API: Includes ScalableIcons, CompoundIcon
> (Overlay, Stack and Pile), ReflectionIcon, MatteIcon, TempIcon +
> support for async image loading in icons. Includes an IconPanel for
> scaling icons easily.
> - Painters: Some extra painters.
> - MultiSizeList: JList extension which provides a HUGE
> amount of flexibility for _WRAP orientations including non-grid
> behavior, stretching and row/column-based sizing.
> - MultiSizeListEditor: Visual editor which overlays the
> above component providing handles and controls for resizing/
> manipulating the context areas.
> - Layouts: Various new layouts and extensions to the built
> in ones.
> - Anything else I can get away with
>
> As I said above this could take a while to filter through the
> management/decision makers but I will let you know if/when it
> happens. If there's anything there that particularly interests
> anyone let me know and I'll focus more on that (or release a
> personal version like I did with the ExtensionRepaintManager if the
> code isn't too big).
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=165969
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
- Blasting forth in three part harmony!
[att1.html]
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 2:02 PM
in response to: Joshua Marinacci
|
|
|
> What do your new Painters do? (The other stuff is
> cool too, but I've
> got painters on the brain right now).
I have one that looks like the selection background in windows vista, it takes two colours for the top and bottom colours, looks nice when using translucent white on a black/dark background + reflection (will be used in the reflection demo mentioned below). I have a glassy button painter that paints like the toolbar in the new windows media player. I also have a fade/bleed painter which paints a soft glow from a single point fading in both directions, looks nice as a hover hint when using the glassy painter or as a background when painted on a reflection line.
I'll attempt to get some screens of them if you like tomorrow
I have extended a few standard SwingX painters to provide needed functionality. The change that springs to mind is the inclusion of a getTextBounds(width, height) method in TextPainter which greatly improves the possible repaint performance when used properly.
All painters I've implemented follow an extended painter API that is based on, but not the same as, the SwingX one. The extension simply adds a coordinate space to the paint method (like you get in Border and Icon) to make the painters a bit more reusable. My paint method has the prototype void paint(Graphics g, T component, int x, int y, int width, int height). The original reason for changing the API was to provide easy support for excluding the component insets in the paint operation, especially useful in a common case where a non-opaque component has a translucent Matte/BackgroundPainter and translucent border (eg a DropShadowBorder), but many other uses were discovered along the way.
> I can't wait for the ReflectionPanel
I'll hopefully get a compiled only demo for you tomorrow resembling what I'm using it for at work.
If I have time then I'll try to get demos of all the above (visual) classes for you to look at plus a bit more of a description of what they're capable of and maybe some examples of how the non-visual utilities can help.
Until tomorrow.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 23, 2006 2:48 PM
in response to: mattnathan
|
|
|
On Oct 23, 2006, at 2:02 PM, jdnc-interest@javadesktop.org wrote:
>> What do your new Painters do? (The other stuff is
>> cool too, but I've
>> got painters on the brain right now).
>
> I have one that looks like the selection background in windows
> vista, it takes two colours for the top and bottom colours, looks
> nice when using translucent white on a black/dark background +
> reflection (will be used in the reflection demo mentioned below). I
> have a glassy button painter that paints like the toolbar in the
> new windows media player. I also have a fade/bleed painter which
> paints a soft glow from a single point fading in both directions,
> looks nice as a hover hint when using the glassy painter or as a
> background when painted on a reflection line.
Sounds great! How much of these are new code and how much are made by
combining the existing painters.
>
> I'll attempt to get some screens of them if you like tomorrow
I can't wait to see them.
> I have extended a few standard SwingX painters to provide needed
> functionality. The change that springs to mind is the inclusion of
> a getTextBounds(width, height) method in TextPainter which greatly
> improves the possible repaint performance when used properly.
Yeah. I've been meaning to add that. It already does this internally
to figure out the positioning. I need to make it public so others can
use it.
> All painters I've implemented follow an extended painter API that
> is based on, but not the same as, the SwingX one. The extension
> simply adds a coordinate space to the paint method (like you get in
> Border and Icon) to make the painters a bit more reusable. My paint
> method has the prototype void paint(Graphics g, T component, int
> x, int y, int width, int height). The original reason for
> changing the API was to provide easy support for excluding the
> component insets in the paint operation, especially useful in a
> common case where a non-opaque component has a translucent Matte/
> BackgroundPainter and translucent border (eg a DropShadowBorder),
> but many other uses were discovered along the way.
So you've just added x/y parameters? Why couldn't the same thing be
done by adjusting the transform on the graphics object before passing
it to the paint method? Essentially moving the work to the parent
painter so the child knows less about the environment.
>
>> I can't wait for the ReflectionPanel
>
> I'll hopefully get a compiled only demo for you tomorrow resembling
> what I'm using it for at work.
>
> If I have time then I'll try to get demos of all the above (visual)
> classes for you to look at plus a bit more of a description of what
> they're capable of and maybe some examples of how the non-visual
> utilities can help.
Sounds great!
Thanks,
Josh
>
> Until tomorrow.
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166098
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
- Blasting forth in three part harmony!
[att1.html]
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 1:20 AM
in response to: Joshua Marinacci
|
|
|
> So you've just added x/y parameters? Why couldn't the
> same thing be
> done by adjusting the transform on the graphics
> object before passing
> it to the paint method? Essentially moving the work
> to the parent
> painter so the child knows less about the
> environment.
It's not the x/y coordinates that raise the problem, the problem is the width/height dimensions. If you use Graphics transforms to scale the paint area then your painters may paint in ways you didn't intend. For example a hash of lines 1 pixel wide and 1 pixel apart will give rendering artifacts when scaled without interpolation. The other way to do this would be to set the clip area, but this is ignored by most painters, instead these painters use component.getWidth()/component.getHeight().
If there is another way to do this then I will convert my code to use this API instead as I'm not happy about writing painters that cannot be used out-the-box with the painters in SwingX. I have implemented copies of all (apart from the Linear/RadialGradient) SwingX painters using this new API which was mostly trivial involving component.getWidth() refactoring to width etc.
Anyway as promised I have screen of my painters for you to look at (the demos will come later :)):
A selection of GlassPainters, the text on top is the base colour and the border is added on afterwards.
http://indomus.co.uk/java/images/GlassPainter.png
Two new painters. The top one is the default VistaSelectionPainter and the bottom one is what I've called a SunrisePainter.
http://indomus.co.uk/java/images/OtherPainters.png
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 2:40 AM
in response to: mattnathan
|
|
|
Ok, have put together a couple of demos and some screens of the Advanced Icon API. The other demos will have to come later as the reflection component is not quite finished yet and the other components don't have ready made demos for me to show you.
Anyway here goes...
Advanced Icon API
The following screens show what is possible with my Icon API. With all the compound icons the layout/paint policy is pluggable so you can do whatever you want with them.
http://indomus.co.uk/java/images/OverlayIcon.png
http://indomus.co.uk/java/images/GridIcon.png
http://indomus.co.uk/java/images/StackIcon.png
http://indomus.co.uk/java/images/PileIcon.png
Demos
Here are some demos that I forgot to mention above. Unfortunately they require all-privileges due to reflection calls (I'm working to remove this).
A rating chooser: select a rating visually or using the keyboard, use the control panel to adjust the settings. In order the settings are:
- Icon Size
- Horizontal alignment
- vertical alignment
- Left to right
- Rating value as a slider
- Maximum number of stars
- Possible precision (number of sections per star). 0 means infinite
The others are labeled
http://indomus.co.uk/java/examples/RatingChooserDemo.jnlp
A Task Bar: similar to the Mac task bar, this provides the ability to have a collection of (grouped) tasks. This demonstrates a use for the SunrisePainter behind the icons. Rollover/selection effects also have the ability to affect neighboring tasks allowing (but not demonstrated) effects like the image panel at the bottom in Aeriths main page.
PS. The image is taken from Romains pictures from a while ago, hope you don't mind.
This demo looks best at 800x600, click Window->800x600 to resize.
http://indomus.co.uk/java/examples/TaskBarDemo.jnlp
Note that in the Task Bar demo the painter behind the tasks is a composite of two sunrise painters painted on top of one another both with different directions. This is one of the reasons I changed the API for swingx Painters.
Will try to get the other demos out when they are ready
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 3:02 AM
in response to: mattnathan
|
|
|
Hi Matt
Excellent.
Btw, the RatingChooserDemo, when run on my machine, has the demo panel
(showing the stars) appear under the main frame--I didn't see anything
happening till I moved it.
Great work, this is all exciting to watch.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 3:10 AM
in response to: Patrick Wright
|
|
|
> Hi Matt
>
> Excellent.
Thanks
> Btw, the RatingChooserDemo, when run on my machine,
> has the demo panel
> (showing the stars) appear under the main frame--I
> didn't see anything
> happening till I moved it.
Yeah sorry about that, it's just lazyness on my part. Should really have mentioned it, guess you can't please everyone
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 4:20 AM
in response to: mattnathan
|
|
|
Just finished a working demo of the ReflectionPanel mentioned above.
This uses Romains new ReflectionRenderer to create the reflection and my ExtensionRepaintManager to extend the repaint area.
There are a couple of issues related to clipping when blurring is enabled and performance could be a lot better. Note: don't change the look and feel as this causes an exception due to the (very old) login component I'm using not supporting it properly.
Anyway enough talk...
http://indomus.co.uk/java/examples/ReflectionPanelDemo.jnlp
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 5:14 AM
in response to: mattnathan
|
|
|
Matt it's excellent! Are the performance problems related to your code (clipping handling for instance) or mine? In any case, removing the blurring might be a good idea I have seen a guy implementing the exact same component with the exact same approach (that is using a RepaintManager to extend the dirty region) and it worked beautifully on QuickTimes movies. Unfortunately, it's closed source.
Try this out: http://ochafik.free.fr/blog/?p=70
>From what I've read in his blog, he got the inspiration from a demo I did for JavaOne 2005 and uses exactly the same approach to render the reflections.
On Tuesday, October 24, 2006, at 01:21PM, <jdnc-interest@javadesktop.org> wrote:
>Just finished a working demo of the ReflectionPanel mentioned above.
>
>This uses Romains new ReflectionRenderer to create the reflection and my ExtensionRepaintManager to extend the repaint area.
>
>There are a couple of issues related to clipping when blurring is enabled and performance could be a lot better. Note: don't change the look and feel as this causes an exception due to the (very old) login component I'm using not supporting it properly.
>
>Anyway enough talk...
>http://indomus.co.uk/java/examples/ReflectionPanelDemo.jnlp
>[Message sent by forum member 'mattnathan' (mattnathan)]
>
>http://forums.java.net/jive/thread.jspa?messageID=166279
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
>For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>
--
Romain Guy <romain.guy@mac.com>
http://www.progx.org
http://jroller.com/page/gfx
http://www.jext.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 5:52 AM
in response to: Romain Guy
|
|
|
The performance problems (at least the ones I know about) are down to my code, I recreate the entire component in a buffer before recreating the entire reflection in another buffer. Not the fastest way to do this I'm sure you'll agree. Once I've got my 'proper'/'important' work done this afternoon I'll look into refining the clipping region to only repaint the bits that need repainting.
Yes I agree that the performance would improve if I removed the blurring but then where's the fun in that . BTW, what's the chance of adding a getBlurRadius (or similar) method to your ReflectionRenderer? I currently hard-code that value (used for computing reflection bounds/clip areas) based on your source. Also a similar addition to what you did with the ShadowRenderer (extending the image) would be nice when blurring is on .
I tried the demo on my Windows XP machine (JSE5) and there are repaint artifacts all over the place. I see what it's supposed to look like though and it's very impressive, I didn't realise that QTJava.zip file contained a Java QuickTime player.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 6:04 AM
in response to: mattnathan
|
|
|
I got lazy with the blur radius but it's on my list. I was just reluctant to add another parameter to the API (I love simple APIs) and the I carefully chose this blur radius to look good in most cases. But I will definitely increase the size of the image when blurring is on. I'm still not sure about get/setBlurRadius though. I might as well add this to prevent myself from further user requests
What I like about the QT/reflection demo is it looks indeed impressive. It shows how fast the component is working. I'd love to write a small demo with QT with a design similar to the current Reflection demo (that I posted on my blog.)
On Tuesday, October 24, 2006, at 02:53PM, <jdnc-interest@javadesktop.org> wrote:
>The performance problems (at least the ones I know about) are down to my code, I recreate the entire component in a buffer before recreating the entire reflection in another buffer. Not the fastest way to do this I'm sure you'll agree. Once I've got my 'proper'/'important' work done this afternoon I'll look into refining the clipping region to only repaint the bits that need repainting.
>
>Yes I agree that the performance would improve if I removed the blurring but then where's the fun in that . BTW, what's the chance of adding a getBlurRadius (or similar) method to your ReflectionRenderer? I currently hard-code that value (used for computing reflection bounds/clip areas) based on your source. Also a similar addition to what you did with the ShadowRenderer (extending the image) would be nice when blurring is on .
>
>I tried the demo on my Windows XP machine (JSE5) and there are repaint artifacts all over the place. I see what it's supposed to look like though and it's very impressive, I didn't realise that QTJava.zip file contained a Java QuickTime player.
>[Message sent by forum member 'mattnathan' (mattnathan)]
>
>http://forums.java.net/jive/thread.jspa?messageID=166309
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
>For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
>
--
Romain Guy <romain.guy@mac.com>
http://www.progx.org
http://jroller.com/page/gfx
http://www.jext.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 9:33 AM
in response to: Romain Guy
|
|
|
I just improved the performance of the reflection panel demo I posted earlier. Sorry I forgot to make a backup of the old code so that they can be compared. The new code takes note of the clip area but does not store any information in a buffer between pain calls.
The link to the demo:
http://indomus.co.uk/java/examples/ReflectionPanelDemo.jnlp
Not bad performance if I do say so myself especially with the blur enabled
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 9:38 AM
in response to: mattnathan
|
|
|
I just committed a new ReflectionRenderer with blur radius support.
The generated image is also larger when blurring is turned on.
On 24 oct. 06, at 18:33, jdnc-interest@javadesktop.org wrote:
> I just improved the performance of the reflection panel demo I
> posted earlier. Sorry I forgot to make a backup of the old code so
> that they can be compared. The new code takes note of the clip area
> but does not store any information in a buffer between pain calls.
>
> The link to the demo:
> http://indomus.co.uk/java/examples/ReflectionPanelDemo.jnlp
>
> Not bad performance if I do say so myself especially with the blur
> enabled
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166454
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 1:40 AM
in response to: Romain GUY
|
|
|
> I just committed a new ReflectionRenderer with blur
> radius support.
> The generated image is also larger when blurring is
> turned on.
Have just checked out your new code, most helpful, thanks.
There are a few bugs in it though which may give odd/unwanted behavior.
- In appendReflection the x coordinate needs to be divided by 2 to give the correct offset.
- I'm not sure if this is intentional but the effective blur radius of a default StackBlurFilter (3 stacks) with radius 1 is 3, as such the returned reflection is clipped more than it should be (might be nice to add getEffcectiveBlurRadius to StackBlurFilter but that's up to you).
- Again not sure if this one is intentional but the height of the reflection image returned from createReflection does not include the blur radius (/effective blur radius). This leads to additional clipping which is more noticeable when there's a gap between the source image and reflection (like in the ReflectionPanel).
Hope this helps.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 4:36 AM
in response to: mattnathan
|
|
|
Thanks for the pointers. I fixed everything but I am not happy with
the results now generated. I do take into account the effective
radius properly and it just doesn't look as nice. Besides, there's a
regression in performance. Before, I used to do this:
reflectionImage.drawImage(sourceImage, blurFilter, x, y);
Now to avoid clipping, here is what I have to do:
reflectionImage.drawImage(sourceImage, null, x, y);
// ...
return blurFilter.filter(reflectionImage, null);
That means there's an extra lengthy operation going on. Hopefully
people won't use blurring too much
On 25 oct. 06, at 10:40, jdnc-interest@javadesktop.org wrote:
>> I just committed a new ReflectionRenderer with blur
>> radius support.
>> The generated image is also larger when blurring is
>> turned on.
>
> Have just checked out your new code, most helpful, thanks.
>
> There are a few bugs in it though which may give odd/unwanted
> behavior.
>
> - In appendReflection the x coordinate needs to be divided by 2 to
> give the correct offset.
> - I'm not sure if this is intentional but the effective blur radius
> of a default StackBlurFilter (3 stacks) with radius 1 is 3, as such
> the returned reflection is clipped more than it should be (might be
> nice to add getEffcectiveBlurRadius to StackBlurFilter but that's
> up to you).
> - Again not sure if this one is intentional but the height of the
> reflection image returned from createReflection does not include
> the blur radius (/effective blur radius). This leads to additional
> clipping which is more noticeable when there's a gap between the
> source image and reflection (like in the ReflectionPanel).
>
> Hope this helps.
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 5:58 AM
in response to: Romain GUY
|
|
|
No problem
I think that the reason the two methods paint differently is because your FastBlur and StackBlur filters do not expand the image to accomodate the edge blurs like the ReflectionRenderer does.
I attempted to extend the StackBlurFilter to correct this myself but unfortunately the filter method uses a package private blur method passing incorrect values. To allow extension would it be possible to derrive the width/height used to create the src/dstPixels array from the dst image instead of the src image? (either that or fix the behaviour completely ;)).
Thanks
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:05 AM
in response to: mattnathan
|
|
|
I know why the two method paints differently. That is not the
problem. My problem is I like better the clipped result
Image filters in Java2D are not meant to increase the size of the
pictures they filter. Think of what happens in Photoshop or The GIMP
for instance. If you blur a picture, it does not change the size of
your picture. I am perfectly fine with increasing the size of the
picture in classes like ShadowRenderer and ReflectionRenderer but
*not* in the filters themselves.
On 25 oct. 06, at 14:58, jdnc-interest@javadesktop.org wrote:
> No problem
>
> I think that the reason the two methods paint differently is
> because your FastBlur and StackBlur filters do not expand the image
> to accomodate the edge blurs like the ReflectionRenderer does.
>
> I attempted to extend the StackBlurFilter to correct this myself
> but unfortunately the filter method uses a package private blur
> method passing incorrect values. To allow extension would it be
> possible to derrive the width/height used to create the src/
> dstPixels array from the dst image instead of the src image?
> (either that or fix the behaviour completely ;)).
>
> Thanks
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166796
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:13 AM
in response to: Romain GUY
|
|
|
On 10/25/06, Romain GUY <romain.guy@mac.com> wrote:
> I know why the two method paints differently. That is not the
> problem. My problem is I like better the clipped result
Would you like to post a sample so the rest of us can chime in on the
differences? So as not to leave the API to a "matter of taste".
Thanks for all the hard work, by the way.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:14 AM
in response to: Patrick Wright
|
|
|
We're not talking about API changes here, but implementation details
On 25 oct. 06, at 15:13, Patrick Wright wrote:
> On 10/25/06, Romain GUY <romain.guy@mac.com> wrote:
>> I know why the two method paints differently. That is not the
>> problem. My problem is I like better the clipped result
>
> Would you like to post a sample so the rest of us can chime in on the
> differences? So as not to leave the API to a "matter of taste".
>
> Thanks for all the hard work, by the way.
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:23 AM
in response to: Romain GUY
|
|
|
On 10/25/06, Romain GUY <romain.guy@mac.com> wrote:
> We're not talking about API changes here, but implementation details
Sorry, I mis-spoke--but there is a difference in behavior here, which
is (by custom) open for review. For example, if you use a different
data structure internally, that's an implementation detail, unless it
causes slower performance/uses more memory in some circumstances,
which is a change in behavior (or capability).
I get the feeling the last few days there is more "jousting" going on
around painters than calm exchange of ideas--my view, anyway.
It would be nice to see the difference in visual effect/outcome you
didn't like; I tend to like your taste in GUI design but it would be
good if we could all see what you are referring to.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:35 AM
in response to: Patrick Wright
|
|
|
http://jext.free.fr/oldReflection.png
http://jext.free.fr/newReflection.png
The new reflection implementation is a more correct/realistic
implementation because it does not clip the blur.
On 25 oct. 06, at 15:23, Patrick Wright wrote:
> On 10/25/06, Romain GUY <romain.guy@mac.com> wrote:
>> We're not talking about API changes here, but implementation
>> details
>
> Sorry, I mis-spoke--but there is a difference in behavior here, which
> is (by custom) open for review. For example, if you use a different
> data structure internally, that's an implementation detail, unless it
> causes slower performance/uses more memory in some circumstances,
> which is a change in behavior (or capability).
>
> I get the feeling the last few days there is more "jousting" going on
> around painters than calm exchange of ideas--my view, anyway.
>
> It would be nice to see the difference in visual effect/outcome you
> didn't like; I tend to like your taste in GUI design but it would be
> good if we could all see what you are referring to.
>
> Regards
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:47 AM
in response to: Romain GUY
|
|
|
Thanks for posting that, Romain.
To me, this picture looks much better a small break between the end of
the mountains and the beginning of the reflection, as in the new
version. But I sort of like how the reflection expands all the way to
the bounds of the image on the other three sides (west, east, south)
on the old version. Something to mull over, anyway.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 6:51 AM
in response to: Patrick Wright
|
|
|
I agree Patrick. A reflection would not cut off the west, east, and south
sides as the picture is placed.
On 10/25/06, Patrick Wright <pdoubleya@gmail.com> wrote:
>
> Thanks for posting that, Romain.
>
> To me, this picture looks much better a small break between the end of
> the mountains and the beginning of the reflection, as in the new
> version. But I sort of like how the reflection expands all the way to
> the bounds of the image on the other three sides (west, east, south)
> on the old version. Something to mull over, anyway.
>
> Regards
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 7:54 AM
in response to: Bill Snyder
|
|
|
From: romain.guy@mac.com
Subject: Re: JXPanel and Translucency
Date: 25 octobre 2006 16:42:48 HAEC
To: jdnc@jdnc.dev.java.net
Remember this is just *one* option. By default the reflection is not blurred and looks perfectly right. I would personally go with the new version as this is what most people would expect I guess.
On 25 oct. 06, at 15:51, Bill Snyder wrote:
I agree Patrick. A reflection would not cut off the west, east, and south sides as the picture is placed.
On 10/25/06, Patrick Wright < pdoubleya@gmail.com> wrote:Thanks for posting that, Romain.
To me, this picture looks much better a small break between the end of
the mountains and the beginning of the reflection, as in the new
version. But I sort of like how the reflection expands all the way to
the bounds of the image on the other three sides (west, east, south)
on the old version. Something to mull over, anyway.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
[att1.html]
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 8:19 AM
in response to: Romain GUY
|
|
|
> I know why the two method paints differently. That is
> not the
> problem. My problem is I like better the clipped
> result
>
> Image filters in Java2D are not meant to increase the
> size of the
> pictures they filter. Think of what happens in
> Photoshop or The GIMP
> for instance. If you blur a picture, it does not
> change the size of
> your picture. I am perfectly fine with increasing the
> size of the
> picture in classes like ShadowRenderer and
> ReflectionRenderer but
> *not* in the filters themselves.
Your right, my apologies, I guess I got a bit wrapped up in my own use case instead of thinking of the bigger picture :S.
I know your not going to like this but what's the chance of giving the user the choice with a property on ReflectionRenderer like reflectionClipped / blurClippingEnabled / reflectionExpansionEnabled / reflectionCreationWithALargerAreaSoThatBlurringIsNotClippedEnabled . I can see cases where both versions could be used, though if I were to choose one I would go with the new version as it's easier to clip off the extra blur yourself than it is to add it on again.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 9:02 AM
in response to: mattnathan
|
|
|
I thought you would propose that I prefer to go with the new
version. I mean, it looks good and I don't see the point of
cluttering the API for such small differences. Besides, blurred
reflections is not the common case (I should never have added this
option in the first place
On 25 oct. 06, at 17:19, jdnc-interest@javadesktop.org wrote:
>> I know why the two method paints differently. That is
>> not the
>> problem. My problem is I like better the clipped
>> result
>>
>> Image filters in Java2D are not meant to increase the
>> size of the
>> pictures they filter. Think of what happens in
>> Photoshop or The GIMP
>> for instance. If you blur a picture, it does not
>> change the size of
>> your picture. I am perfectly fine with increasing the
>> size of the
>> picture in classes like ShadowRenderer and
>> ReflectionRenderer but
>> *not* in the filters themselves.
>
> Your right, my apologies, I guess I got a bit wrapped up in my own
> use case instead of thinking of the bigger picture :S.
>
> I know your not going to like this but what's the chance of giving
> the user the choice with a property on ReflectionRenderer like
> reflectionClipped / blurClippingEnabled /
> reflectionExpansionEnabled /
> reflectionCreationWithALargerAreaSoThatBlurringIsNotClippedEnabled .
> I can see cases where both versions could be used, though if I
> were to choose one I would go with the new version as it's easier
> to clip off the extra blur yourself than it is to add it on again.
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166849
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 9:19 AM
in response to: Romain GUY
|
|
|
> I thought you would propose that
You know me too well already .
> (I should never have added this
> option in the first place
You can't go back now . Anyway I like the bluring option, makes it look much better.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 9:23 AM
in response to: mattnathan
|
|
|
Well I propose to leave it like it is right now.
On 25 oct. 06, at 18:19, jdnc-interest@javadesktop.org wrote:
>> I thought you would propose that
>
> You know me too well already .
>
>> (I should never have added this
>> option in the first place
>
> You can't go back now . Anyway I like the bluring option, makes
> it look much better.
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166899
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 10:28 AM
in response to: Romain GUY
|
|
|
I agree with Patrick and Bill. The new one looks correct on the north edge, but doesn't look right on the east and west. I wouldn't expect the reflection to stop on the sides. Personally, I like the blurred reflection. Do you have screenshots of it with and without the blurred reflection?
Erik
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 11:00 AM
in response to: evickroy
|
|
|
It looks even worse when the reflection extends beyond the edges. I
personally think the current version is more correct than a version
that would expand the reflection beyond the edges.
Reflection without blur: http://jext.free.fr/reflection-noblur.png
On 25 oct. 06, at 19:28, jdnc-interest@javadesktop.org wrote:
> I agree with Patrick and Bill. The new one looks correct on the
> north edge, but doesn't look right on the east and west. I
> wouldn't expect the reflection to stop on the sides. Personally, I
> like the blurred reflection. Do you have screenshots of it with
> and without the blurred reflection?
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166929
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 11:09 AM
in response to: Romain GUY
|
|
|
Just to be clear, this latest screenshot without the blur is the "new" way without blurring?
This screenshot without the blur looks correct to me since it extends the reflection to the full size on the east and west edges, which is how the "old" blurred image looks.
Erik
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 11:21 AM
in response to: evickroy
|
|
|
The non-blurred version has always been like that. I tended to prefer
the old blur but the more I think about it the more I think the new
one is right. It makes a lot more sense when you increase the length,
the blur radius and the opacity. The "problem" with the new blur is
that it DOES extend to the full size on the east and west but the
blur filter "shrinks it" (well, not really, but that's what it looks
like.)
I just had an idea about how I could "fix" this. Let me try and I'll
get back to you guys.
On 25 oct. 06, at 20:09, jdnc-interest@javadesktop.org wrote:
> Just to be clear, this latest screenshot without the blur is the
> "new" way without blurring?
>
> This screenshot without the blur looks correct to me since it
> extends the reflection to the full size on the east and west edges,
> which is how the "old" blurred image looks.
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166958
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 11:50 AM
in response to: Romain GUY
|
|
|
Ok forget it, my idea does not work well.
On 25 oct. 06, at 20:21, Romain GUY wrote:
> The non-blurred version has always been like that. I tended to
> prefer the old blur but the more I think about it the more I think
> the new one is right. It makes a lot more sense when you increase
> the length, the blur radius and the opacity. The "problem" with the
> new blur is that it DOES extend to the full size on the east and
> west but the blur filter "shrinks it" (well, not really, but that's
> what it looks like.)
>
> I just had an idea about how I could "fix" this. Let me try and
> I'll get back to you guys.
>
> On 25 oct. 06, at 20:09, jdnc-interest@javadesktop.org wrote:
>
>> Just to be clear, this latest screenshot without the blur is the
>> "new" way without blurring?
>>
>> This screenshot without the blur looks correct to me since it
>> extends the reflection to the full size on the east and west
>> edges, which is how the "old" blurred image looks.
>>
>> Erik
>> [Message sent by forum member 'evickroy' (evickroy)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=166958
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
>> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>>
>
> --
> Romain GUY <romain.guy@mac.com>
> http://jroller.com/page/gfx
> http://www.progx.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 11:55 AM
in response to: Romain GUY
|
|
|
Ok. So you guys are going to punt, for now, on making the blurred reflection look right?
Erik
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 25, 2006 12:02 PM
in response to: evickroy
|
|
|
It *does* look right.
On 25 oct. 06, at 20:55, jdnc-interest@javadesktop.org wrote:
> Ok. So you guys are going to punt, for now, on making the blurred
> reflection look right?
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166990
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 26, 2006 9:10 AM
in response to: Romain GUY
|
|
|
For those of you who are still interested I have just created a new ReflectionPanel demo with all bugs fixed and some user controls for you to adjust how you want the reflection to look. Gap, length, opacity, blur enabled and blur radius in that order.
I've also added a few extra options to the Edit->Background menu so you can see it with different views (the Seascape background is the one use in the application I'm writing at work designed to be used in a similar situation to the demo). You still can't change the look and feel I'm afraid.
http://indomus.co.uk/java/examples/ReflectionPanelDemo2.jnlp
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 27, 2006 2:28 AM
in response to: mattnathan
|
|
|
This is awesome. Great work.
I love seeing the text I type in appear in the reflected image in real-time (with no delay).
Would it be possible to show the reflected password in cleartext, but upside down and backward? haha
Very nice work, glad you have joined the discussion. Keep it up!
Patrick
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 27, 2006 2:38 AM
in response to: pdoubleya
|
|
|
>
> I love seeing the text I type in appear in the
> reflected image in real-time (with no delay).
>
hadn't noticed - forgot to input anything because I was already so very impressed by simply playing with the reflection
Great work!
Jeanette
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 27, 2006 3:30 AM
in response to: pdoubleya
|
|
|
> This is awesome. Great work.
>
> I love seeing the text I type in appear in the
> reflected image in real-time (with no delay).
>
Thanks, that was the main reason I wrote this component. That plus it was a bit of fun (in an otherwise dull week) and an Extreme GUI Makeover for the application I was working on (see the differences here http://indomus.co.uk/images/oldlogin.png and http://indomus.co.uk/images/newlogin.png).
> Would it be possible to show the reflected password
> in cleartext, but upside down and backward? haha
>
Isn't that just rotated by 180?
> Very nice work, glad you have joined the discussion.
> Keep it up!
>
> Patrick
I'm about to start work on a generic superclass to both the reflection panel and the shadow panel (possibly the translucent panel too) which takes an effect and does all the performance clipping and painting for you. This should make writing advanced effects that update in real-time with the source components as simple as writing the effects themselves.
I'll get a demo out as soon as I can and if you have any effects you want to see then let me know. I think for starters I'll get reflection, shadow, blur and translucency effects working to try and prove it can be done.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 26, 2006 9:52 AM
in response to: Romain GUY
|
|
|
Ok. I don't want to start any arguments here, and I do agree that they all look really good. I just have one question, though. Why does the non-blurred reflection match the width of the original image, but the blurred reflection does not?
http://jext.free.fr/reflection-noblur.png
http://jext.free.fr/newReflection.png
> It *does* look right.
>
> On 25 oct. 06, at 20:55,
> jdnc-interest@javadesktop.org wrote:
>
> > Ok. So you guys are going to punt, for now, on
> making the blurred
> > reflection look right?
> >
> > Erik
> > [Message sent by forum member 'evickroy'
> (evickroy)]
> >
> >
> http://forums.java.net/jive/thread.jspa?messageID=1669
> 90
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> jdnc-unsubscribe@jdnc.dev.java.net
> > For additional commands, e-mail:
> jdnc-help@jdnc.dev.java.net
> >
>
> --
> Romain GUY <romain.guy@mac.com>
> http://jroller.com/page/gfx
> http://www.progx.org
>
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail:
> jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 26, 2006 12:02 PM
in response to: evickroy
|
|
|
> Ok. I don't want to start any arguments here, and I
> do agree that they all look really good. I just have
> one question, though. Why does the non-blurred
> reflection match the width of the original image, but
> the blurred reflection does not?
>
> http://jext.free.fr/reflection-noblur.png
>
> http://jext.free.fr/newReflection.png
I have been scratching my head about this one too. The reflected image is actually bigger than the source image by 2*effectiveBlurRadius (which looks like its about 15 in the screen shot [3*5]) so the narrowing is a purely perceived one.
I'm not sure but I think the problem is a combination of the reflected image being on a dark background and a small oversight in the filter code. From what I understand of the filter it does a blur using the colour values found in each pixel in the image, when a section of the image is used that has unset areas then those have colour values of [0, 0, 0, 0], which is blurred the same as black with alpha, darkening the surrounding pixels.
You can see this effect more clearly if you run my demo and change the background colour to white when blurring is enabled: http://indomus.co.uk/java/images/blur-darkening.png
(there should be no dark border around the reflection)
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 9:15 AM
in response to: mattnathan
|
|
|
> Ok, have put together a couple of demos and some
> screens of the Advanced Icon API. The other demos
> will have to come later as the reflection component
> is not quite finished yet and the other components
> don't have ready made demos for me to show you.
Wow, cool stuff! Any chance we can get you to sign the JCA and contribute the source code for these?
Richard
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 9:07 AM
in response to: mattnathan
|
|
|
> > So you've just added x/y parameters? Why couldn't
> the
> > same thing be
> > done by adjusting the transform on the graphics
> > object before passing
> > it to the paint method? Essentially moving the
> work
> > to the parent
> > painter so the child knows less about the
> > environment.
>
> It's not the x/y coordinates that raise the problem,
> the problem is the width/height dimensions. If you
> use Graphics transforms to scale the paint area then
> your painters may paint in ways you didn't intend.
> For example a hash of lines 1 pixel wide and 1 pixel
> apart will give rendering artifacts when scaled
> without interpolation. The other way to do this would
> be to set the clip area, but this is ignored by most
> painters, instead these painters use
> component.getWidth()/component.getHeight().
Actually, in the painter_work branch, we changed the Painter interface to take a width and height, but not an X and Y (preferring to let the graphics context be shifted instead, so that all painting is relative to 0, 0). So, we came to the same conclusion a month ago .
Richard
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 1:52 PM
in response to: rbair
|
|
|
> Actually, in the painter_work branch, we changed the
> Painter interface to take a width and height, but not
> an X and Y (preferring to let the graphics context be
> shifted instead, so that all painting is relative to
> 0, 0). So, we came to the same conclusion a month ago
> .
>
> Richard
I didn't realise this had been implemented. I wrote those painters more than 3 months ago using the then recent SwingX source as a guide. I'll have to look into the painter_work branch to see what other wonders it contains .
> Wow, cool stuff! Any chance we can get you to sign the
> JCA and contribute the source code for these?
As mentioned before in an earlier post I've started discussion with my work to release the source for the demos and images you've seen here (plus a few more). If the code isn't too big (one or two files) I don't mind replicating it if people want me too but some of it required some heavy head scratching (like the icons) and I'm sure you know the feeling of not wanting to solve a problem twice. I do intend to sign the JCA at some point though and contribute what I can.
> Very nice. Is this all custom code or built by combining standard
> painters? I think you could do this now with existing ones by
> subclassing CompoundPainter and initializing the painters with the
> right colors.
They're all custom code, but I'm sure your right, they are just a pair of gradients bolted together. The text on top is added afterwards to show what colour was passed in the constructor and is painted via a CompoundPainter.
> Very nice. Again I think you could wrap standard painters with the
> right values to get this.
Thanks. What do you think the best way to achieve the sunrise effect would be using existing painters? At the moment it simply does a transparency mask in both x and y dimensions.
> I just committed a new ReflectionRenderer with blur radius support.
> The generated image is also larger when blurring is turned on.
I'll alter my code tomorrow .
There's one other performance tweak that would benefit the ReflectionPanel but which I'm not sure will be used in other places. Would it be posible to add more fine grained control to the reflection generation in the form of limiting the portion of the reflection that is processed. This is probably better explained through an example.
Say I have an Image (20x100) that translates into a reflection with dimensions 20x60, what I'd like to do is ask the renderer for a portion of that reflection (also maybe from a portion of the source image) say 0,30 to 20,60 (or maybe just y coordinates) and this image is returned. This would improve the performance of the ReflectionPanel as it would allow it to respect the clip areas height as well as its width which it can currently only support.
The implementation of this feature would be trivial involving translating the gradient masks start and end coordinates but it's up to you whether you want to add the extra API.
Glad to hear all the feedback, I just hope I can release all that I want to release.
Matt
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 1:58 PM
in response to: mattnathan
|
|
|
I understand what you want in the ReflectionRenderer but that won't
happen In fact, I was waiting for your next email concerning
performance to suggest you do the reflection without
ReflectionRenderer. The code is really small (just a few lines) and
this would give you all the control you need. Besides, you would be
able to cache the gradient used for the reflection, which would
improve the performance even more (makes me think I have a
performance tweak to implement in ReflectionRenderer by making the
gradient cyclic.)
On 24 oct. 06, at 22:52, jdnc-interest@javadesktop.org wrote:
>> Actually, in the painter_work branch, we changed the
>> Painter interface to take a width and height, but not
>> an X and Y (preferring to let the graphics context be
>> shifted instead, so that all painting is relative to
>> 0, 0). So, we came to the same conclusion a month ago
>> .
>>
>> Richard
>
> I didn't realise this had been implemented. I wrote those painters
> more than 3 months ago using the then recent SwingX source as a
> guide. I'll have to look into the painter_work branch to see what
> other wonders it contains .
>
>
>> Wow, cool stuff! Any chance we can get you to sign the
>> JCA and contribute the source code for these?
>
> As mentioned before in an earlier post I've started discussion with
> my work to release the source for the demos and images you've seen
> here (plus a few more). If the code isn't too big (one or two
> files) I don't mind replicating it if people want me too but some
> of it required some heavy head scratching (like the icons) and I'm
> sure you know the feeling of not wanting to solve a problem twice.
> I do intend to sign the JCA at some point though and contribute
> what I can.
>
>
>> Very nice. Is this all custom code or built by combining standard
>> painters? I think you could do this now with existing ones by
>> subclassing CompoundPainter and initializing the painters with the
>> right colors.
>
> They're all custom code, but I'm sure your right, they are just a
> pair of gradients bolted together. The text on top is added
> afterwards to show what colour was passed in the constructor and is
> painted via a CompoundPainter.
>
>
>> Very nice. Again I think you could wrap standard painters with the
>> right values to get this.
>
> Thanks. What do you think the best way to achieve the sunrise
> effect would be using existing painters? At the moment it simply
> does a transparency mask in both x and y dimensions.
>
>
>> I just committed a new ReflectionRenderer with blur radius support.
>> The generated image is also larger when blurring is turned on.
>
> I'll alter my code tomorrow .
>
> There's one other performance tweak that would benefit the
> ReflectionPanel but which I'm not sure will be used in other
> places. Would it be posible to add more fine grained control to the
> reflection generation in the form of limiting the portion of the
> reflection that is processed. This is probably better explained
> through an example.
>
> Say I have an Image (20x100) that translates into a reflection with
> dimensions 20x60, what I'd like to do is ask the renderer for a
> portion of that reflection (also maybe from a portion of the source
> image) say 0,30 to 20,60 (or maybe just y coordinates) and this
> image is returned. This would improve the performance of the
> ReflectionPanel as it would allow it to respect the clip areas
> height as well as its width which it can currently only support.
>
> The implementation of this feature would be trivial involving
> translating the gradient masks start and end coordinates but it's
> up to you whether you want to add the extra API.
>
>
> Glad to hear all the feedback, I just hope I can release all that I
> want to release.
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166564
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
http://www.progx.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 2:33 PM
in response to: Romain GUY
|
|
|
> I understand what you want in the ReflectionRenderer
> but that won't
> happen In fact, I was waiting for your next email
> concerning
> performance to suggest you do the reflection without
>
> ReflectionRenderer. The code is really small (just a
> few lines) and
> this would give you all the control you need.
> Besides, you would be
> able to cache the gradient used for the reflection,
> which would
> improve the performance even more (makes me think I
> have a
> performance tweak to implement in ReflectionRenderer
> by making the
> gradient cyclic.)
Fair enough, I knew it was a long-shot . I'll have a look at what I can do to improve performance some more tomorrow. Also there's a bug in the code whereby the reflection cannot be painted without the original image (try dragging the window off the bottom of the screen and back again to see what I mean) which a reflection buffer would help with.
Matt
PS. Thanks for the reminder about the cyclic gradients, I'd forgotten about that one too.
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Oct 24, 2006 10:12 AM
in response to: mattnathan
|
|
|
On Oct 24, 2006, at 1:20 AM, jdnc-interest@javadesktop.org wrote:
>> So you've just added x/y parameters? Why couldn't the
>> same thing be
>> done by adjusting the transform on the graphics
>> object before passing
>> it to the paint method? Essentially moving the work
>> to the parent
>> painter so the child knows less about the
>> environment.
>
> It's not the x/y coordinates that raise the problem, the problem is
> the width/height dimensions. If you use Graphics transforms to
> scale the paint area then your painters may paint in ways you
> didn't intend. For example a hash of lines 1 pixel wide and 1 pixel
> apart will give rendering artifacts when scaled without
> interpolation. The other way to do this would be to set the clip
> area, but this is ignored by most painters, instead these painters
> use component.getWidth()/component.getHeight().
>
Maybe you are looking at an older version of the code. In the
painter_work CVS branch we have changed the paint method to provide
width and height values and all of the painters have been modified to
use it. Most painters don't use the component at all anymore. It's
just there in case the painter wants additional information. I think
the component is now only used by the text painter to get the text
and font from the component (if it is of an appropriate type).
Because painters used the width and height passed in these values can
be manipulated before hand. A JXPanel could reserve spacing for the
borders, for example.
> If there is another way to do this then I will convert my code to
> use this API instead as I'm not happy about writing painters that
> cannot be used out-the-box with the painters in SwingX. I have
> implemented copies of all (apart from the Linear/RadialGradient)
> SwingX painters using this new API which was mostly trivial
> involving component.getWidth() refactoring to width etc.
>
> Anyway as promised I have screen of my painters for you to look at
> (the demos will come later :)):
>
> A selection of GlassPainters, the text on top is the base colour
> and the border is added on afterwards.
> http://indomus.co.uk/java/images/GlassPainter.png
Very nice. Is this all custom code or built by combining standard
painters? I think you could do this now with existing ones by
subclassing CompoundPainter and initializing the painters with the
right colors.
> Two new painters. The top one is the default VistaSelectionPainter
> and the bottom one is what I've called a SunrisePainter.
> http://indomus.co.uk/java/images/OtherPainters.png
Very nice. Again I think you could wrap standard painters with the
right values to get this. I like the colors you've chosen.
- J
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=166213
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
- Blasting forth in three part harmony!
[att1.html]
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Nov 3, 2006 10:50 AM
in response to: mattnathan
|
|
|
Hi Matt,
Wow, what a thread!
I'm still catching up from being on vacation, but I owe you a response
to your ideas.
I like your API as a way to modify the region that gets painted when
outside of core. It's very similar to the technique employed by
RepaintManagerX; just extensible. I could quibble a bit over the API,
but the approach is good.
For 1.7 I plan on adding a handful of things to make it easier to
customize painting. When in core this could be simplified by adding a
method to JComponent that controls the region and what parent gets
painted. Perhaps something like:
protected XXX extendRepaintRegion Component dirtyDescendant, int x, int
y, int w, int h);
I have to think on the return value a bit. It appears you want to modify
the region that gets repainted, right? I know JXPanel also needs to
trigger painting at the parent of the JXPanel. As such, the return value
would have to incorporate both of these.
Thoughts?
-Scott
jdnc-interest@javadesktop.org wrote:
> Thanks for the confirmation I can stop banging my head on my desk now .
>
> As a result of this problem I have been working on a generic
> RepaintManager extension API for use in this case and others (namely a
> MirrorPanel that I've been having trouble with). Unfortunately I have
> developed this as part of a company project so cant post/commit the code
> just yet (will try to convince my boss to let me, otherwise will
> redevelop in my own time).
>
> A general description of how the API works is as follows.
>
> Define an interface which is able to adjust the properties of the
> addDirtyRegion method in RepaintManager (something like JComponent
> extendDirtyRegion(JComponent original, Rectangle dirtyRegion)) which
> components can implement if they require changes to this behavior. When
> addDirtyRegion is called the extended RepaintManager goes up the
> component tree to find classes who implement this interface. If found
> the extension methods are called adjusting the repaint region and source
> component. Once the root has been reached the default RepaintManager's
> addDirtyRegion method is called with the new dirty region and source
> component.
>
> If done properly all you need to do to get painting to start at your
> translucent panel is implement RMExtension (or whatever its called) with:
> > public JComponent extendDirtyRegion(JComponent original, Rectangle dirtyRegion) {
> return this;
> }
>
> and install the new RepaintManager.
>
> This approach lets you do all sorts of amazing effects with ease. As
> well as translucency you can do mirroring (like the reflecting icons in
> Arieth), bleeding (like the startup pearl in Vista for those who have
> it), stacking (that effect you get from the old superman films starting
> credits ;)), or whatever you want. Each of these effects will update in
> real-time as child components are repainted (i.e. showing the blinking
> caret in a text box, the indeterminate part of a progress bar, button
> rollover effects, etc) and can give some very interesting UIs.
>
> I will work hard to get this code released but you should have enough
> information here to be able to implement your own if you can't wait .
>
> Hope this helps and please post any comments or questions you have (or
> if this has already been implemented elsewhere).
>
> Matt
> [Message sent by forum member 'mattnathan' (mattnathan)]
>
> http://forums.java.net/jive/thread.jspa?messageID=165078
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Nov 6, 2006 6:20 AM
in response to: Scott Violet
|
|
|
> Hi Matt,
>
> Wow, what a thread!
>
> I'm still catching up from being on vacation, but I
> owe you a response
> to your ideas.
>
Thanks for the response and I hope you had a good holiday
> For 1.7 I plan on adding a handful of things to make
> it easier to
> customize painting.
This is great news, can't wait to hear about it all.
> I like your API as a way to modify the region that
> gets painted when
> outside of core. It's very similar to the technique
> employed by
> RepaintManagerX; just extensible. I could quibble a
> bit over the API,
> but the approach is good.
>
> When in core this could be
> simplified by adding a
> method to JComponent that controls the region and
> what parent gets
> painted. Perhaps something like:
>
> protected XXX extendRepaintRegion Component
> dirtyDescendant, int x, int
> y, int w, int h);
>
> It appears
> you want to modify
> the region that gets repainted, right? I know JXPanel
> also needs to
> trigger painting at the parent of the JXPanel. As
> such, the return value
> would have to incorporate both of these.
>
> Thoughts?
>
> -Scott
My API has changed a little since this post, the prototype now reads
public boolean extendDirtyRegion(JComponent source, Rectangle dirtyRegion)
with the returned boolean denoting that this component should become the repaint source. I agree with you that there are two parts to a dirty region, the source and the area, and that this method should be able to return both. As you can't do that in Java (which is a good thing) I decided the best (read simplest) way was to give a rectangle that can be modified to represent the dirty area instead of the separate x, y, w, h bounds. I am open to (and welcome) discussion of the API as I know it can't be perfect.
> I know JXPanel
> also needs to
> trigger painting at the parent of the JXPanel.
From what I can tell the painting actually starts form the JXPanel itself not it's parent or am I missing something?
Matt
BTW the similarity to RepaintManagerX is not a coincidence as this was my starting point .
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Nov 6, 2006 11:42 AM
in response to: mattnathan
|
|
|
Hi Matt,
> My API has changed a little since this post, the prototype now reads
> public boolean extendDirtyRegion(JComponent source, Rectangle dirtyRegion)
> with the returned boolean denoting that this component should become the repaint source. I agree with you that there are two parts to a dirty region, the source and the area, and that this method should be able to return both. As you can't do that in Java (which is a good thing) I decided the best (read simplest) way was to give a rectangle that can be modified to represent the dirty area instead of the separate x, y, w, h bounds. I am open to (and welcome) discussion of the API as I know it can't be perfect.
>
>> I know JXPanel
>> also needs to
>> trigger painting at the parent of the JXPanel.
>
>
> From what I can tell the painting actually starts form the JXPanel
> itself not it's parent or am I missing something?
JXPanel, when the alpha is < 1, is really not opaque. That means
painting must start from an ancestor for things to look right. The
current code in JXPanel invokes setOpaque(false) when setAlpha(<1) is
invoked. This forces painting to eventually occur from an ancestor.
-Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Nov 7, 2006 12:43 AM
in response to: Scott Violet
|
|
|
> Hi Matt,
>
> > My API has changed a little since this post, the
> prototype now reads
> > public boolean extendDirtyRegion(JComponent
> source, Rectangle dirtyRegion)
> > with the returned boolean denoting that this
> component should become the repaint source. I agree
> with you that there are two parts to a dirty region,
> the source and the area, and that this method should
> be able to return both. As you can't do that in Java
> (which is a good thing) I decided the best (read
> simplest) way was to give a rectangle that can be
> modified to represent the dirty area instead of the
> separate x, y, w, h bounds. I am open to (and
> welcome) discussion of the API as I know it can't be
> perfect.
> >
> >> I know JXPanel
> >> also needs to
> >> trigger painting at the parent of the JXPanel.
> >
> >
> > From what I can tell the painting actually starts
> form the JXPanel
> > itself not it's parent or am I missing something?
>
> JXPanel, when the alpha is < 1, is really not opaque.
> That means
> painting must start from an ancestor for things to
> look right. The
> current code in JXPanel invokes setOpaque(false) when
> setAlpha(<1) is
> invoked. This forces painting to eventually occur
> from an ancestor.
>
> -Scott
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail:
> jdnc-help@jdnc.dev.java.net
Apologies, what I meant when I said 'painting starts from JXPanel' was that the repaint event source was the JXPanel and that JXPanel.paintImmediately would be called which would find the first ancestor which is non-opaque and start painting from there. Just as you said. What I read from trigger painting at the parent of the JXPanel was that the RepaintManagerX would set the dirty component as an ancestor of JXPanel directly, which it doesn't.
Sorry for the confusion .
|
|
|
|
|
|
|
|
|
Re: JXPanel and Translucency
Posted:
Nov 7, 2006 2:34 PM
in response to: mattnathan
|
|
|
jdnc-interest@javadesktop.org wrote:
>> Hi Matt,
>>
>>> My API has changed a little since this post, the
>> prototype now reads
>>> public boolean extendDirtyRegion(JComponent
>> source, Rectangle dirtyRegion)
>>> with the returned boolean denoting that this
>> component should become the repaint source. I agree
>> with you that there are two parts to a dirty region,
>> the source and the area, and that this method should
>> be able to return both. As you can't do that in Java
>> (which is a good thing) I decided the best (read
>> simplest) way was to give a rectangle that can be
>> modified to represent the dirty area instead of the
>> separate x, y, w, h bounds. I am open to (and
>> welcome) discussion of the API as I know it can't be
>> perfect.
>>>
>>>> I know JXPanel
>>>> also needs to
>>>> trigger painting at the parent of the JXPanel.
>>>
>>>
>>> From what I can tell the painting actually starts
>> form the JXPanel
>>> itself not it's parent or am I missing something?
>> JXPanel, when the alpha is < 1, is really not opaque.
>> That means
>> painting must start from an ancestor for things to
>> look right. The
>> current code in JXPanel invokes setOpaque(false) when
>> setAlpha(<1) is
>> invoked. This forces painting to eventually occur
>> from an ancestor.
>>
>> -Scott
>>
>> ------------------------------------------------------
>> ---------------
>> To unsubscribe, e-mail:
>> jdnc-unsubscribe@jdnc.dev.java.net
>> For additional commands, e-mail:
>> jdnc-help@jdnc.dev.java.net
>
> Apologies, what I meant when I said 'painting starts from JXPanel' was
> that the repaint event source was the JXPanel and that
> JXPanel.paintImmediately would be called which would find the first
> ancestor which is non-opaque and start painting from there. Just as you
> said. What I read from trigger painting at the parent of the
> JXPanel was that the RepaintManagerX would set the dirty component
> as an ancestor of JXPanel directly, which it doesn't.
>
> Sorry for the confusion .
You got it right Nathan. Painting is so overloaded;)
-Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
java.net RSS
){kind=link}
