Bug 185202 - [CTabFolder] antialias should preserve colors
Summary: [CTabFolder] antialias should preserve colors
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.6 M4   Edit
Assignee: Lakshmi P Shanmugam CLA
QA Contact: Kevin Barnes CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-02 15:29 EDT by Kevin McGuire CLA
Modified: 2009-12-01 10:54 EST (History)
7 users (show)

See Also:


Attachments
patch with code changes (7.36 KB, patch)
2009-03-23 15:41 EDT, Lakshmi P Shanmugam CLA
no flags Details | Diff
new patch with code changes (8.22 KB, patch)
2009-03-31 15:09 EDT, Lakshmi P Shanmugam CLA
no flags Details | Diff
modified patch (7.99 KB, patch)
2009-06-26 08:38 EDT, Lakshmi P Shanmugam CLA
no flags Details | Diff
patch (7.77 KB, patch)
2009-10-26 15:18 EDT, Kevin Barnes CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin McGuire CLA 2007-05-02 15:29:18 EDT
CTabFolder.antialias allocs colors which it then disposes.

  org.eclipse.swt.custom.CTabFolder.antialias(CTabFolder.java:505)
  org.eclipse.swt.custom.CTabFolder.drawTabArea(CTabFolder.java:1130)
  org.eclipse.swt.custom.CTabFolder.onPaint(CTabFolder.java:2257)

It would be a better design to preserve (cache) them.
Comment 1 Lakshmi P Shanmugam CLA 2009-03-23 15:36:08 EDT
CTabFolder.antalias() is called from CTabFolder.drawTabArea() and CTabItem.drawSelected(). The Color can take different values when called from these  2 functions. Hence, we need maintain different cache for the Colors(for TabArea, for Inner selection and outer selection). And calls to antalias() happen alternatively from the 2 functions.
Hence, I was not sure if will it be effective to maintain these caches.
Taking example of the snippet 165, a CTabFolder with 7 TabItems, everytime a Tab is selected, the Color is computed and created again for both Tabarea and the selection. Trying to resize the shell, makes a lot many calls to antalias where the Color is computed & created & disposed again.
So, tried to preserve the Color values for TabArea and Selection and used the same snippet. The Colors are computed & created just once. But, there is an overhead of setting and getting the Colors on each call to antalias().
Is it better to cache/set/get the Color or create it each time in this case?
Comment 2 Lakshmi P Shanmugam CLA 2009-03-23 15:41:02 EDT
Created attachment 129633 [details]
patch with code changes

Created caches for the Color for tabarea and Selection seperately.
Comment 3 Lakshmi P Shanmugam CLA 2009-03-23 15:49:33 EDT
Is there an existing design for this, which I can look into?
Comment 4 Carolyn MacLeod CLA 2009-03-30 01:26:36 EDT
Actually, you don't need the overhead of setting and getting on each call.

Instead, you can cache 3 colors (they can be null if there are gradients etc):
  tabAreaOuterColor
  selectedInnerColor
  selectedOuterColor

The 3 colors need to be (re)computed in 5 places (each of these 5 places will probably only be called at most once per CTabFolder):
  CTabFolder.init()
  CTabFolder.setBackground(Color)  (call super, compute colors, redraw)
  CTabFolder.setBackgroundImage(Image)  (add this method to call super, compute colors, redraw)
  CTabFolder.setSelectionBackground(Color)  (compute colors before redraw)
  CTabFolder.setSelectionBackground(Image)

Dispose the colors in onDispose(event) and every time you recompute them.

Note that antialias does not need the lineRGB parameter if colors are cached, and the other RGB parameters should now be Colors.

A couple of other small notes:
- we almost never use the 'private' access modifier - we prefer to use default (i.e. no modifiers, or 'package access') instead of private. This way, for example, CTabItem can easily access a field in CTabFolder.
- please use tabArea and not tabarea, because it is 2 words
- please use antialias and not antalias
    http://en.wikipedia.org/wiki/Anti-aliasing
- please don't append 'Cache' to the variable names - it's not necessary
Comment 5 Carolyn MacLeod CLA 2009-03-30 14:52:54 EDT
I meant to add "compute colors before redraw" for
CTabFolder.setSelectionBackground(Image)
also.
Comment 6 Lakshmi P Shanmugam CLA 2009-03-31 15:09:29 EDT
Created attachment 130446 [details]
new patch with code changes

Created patch based on the comments above.

Carolyn, I have added the public method CTabFolder.setBackgroundImage(Image) which overrides the Control.setBackgroundImage(Image). Since the background image is set in Control.backgroundImage, should I also replace bgImage in CTabFolder with Control.backgroundImage as a part of this fix?
If not so, we are not using the Control.backgroundImage while computing the color, I'm not sure why we need to recompute the colors in this method.
Comment 7 Lakshmi P Shanmugam CLA 2009-04-02 06:54:29 EDT
Comment on attachment 130446 [details]
new patch with code changes

Marking this patch as obsolete.
The caching uses CTabFolder.borderColor which should not be cached. The bug 270670 has been filed for this and has to fixed before we can fix this.
Comment 8 Carolyn MacLeod CLA 2009-06-25 15:01:25 EDT
I am not sure what the status of this bug is. Is there a missing patch?
Comment 9 Lakshmi P Shanmugam CLA 2009-06-26 08:38:58 EDT
Created attachment 140217 [details]
modified patch

We use border color while computing the antialias colors. But, since we don't cache  the border color now, I have reworked the patch.

In the patch, the border color used to compute the antialias colors is cached. And before using the cached antialias colors, the current border color is verified to be same as cached border color. If the border color has changed, then the antialias colors are computed again.
Comment 10 Kevin Barnes CLA 2009-10-26 15:18:50 EDT
Created attachment 150547 [details]
patch

Patch looks good. I just changed 'borderColorUsed' to 'lastBorderColor' to be consistent with other variables in SWT.
Comment 11 Kevin Barnes CLA 2009-12-01 10:54:57 EST
fixed > 20091201