This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 108859 - Add parameters/methods for possible rendering optimization
Summary: Add parameters/methods for possible rendering optimization
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Graph (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@platform
Depends on:
Blocks: 105060
  Show dependency tree
Reported: 2007-07-04 12:55 UTC by Sergey Petrov
Modified: 2007-07-24 15:10 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Petrov 2007-07-04 12:55:41 UTC
in current realization I'm checking transform to simplify drawing in satellite view, it may not be the best way always
because for example for printing even small image can have a lot of details and time isn't critical for printing,
RenderingHints can be used for similar task, I see useful KEY_RENDERING key with VALUE_RENDER_QUALITY (for printing and
exporting for example), VALUE_RENDER_DEFAULT (for scene view), and VALUE_RENDER_SPEED (for overview with most
optimization always on)
Not sure but may it's not necessary to use only predefined keys/values if it will be used only in own paintWidget methods.
Comment 1 Sergey Petrov 2007-07-04 13:21:05 UTC
Got update on usage of RenderingHints, if it's used for device behavior  adjustment it may not be good for our task, but
it's good to have support for different rendering based on additional information, or it's good to introduce two new
- print() (see JComponent) with default implementation to call paint() and not final.. my expected use: may be realized
by widgets in best quality for texts and without any optimizations, but may be with separate color profile (for example
without gradients etc)
- paintOverview() (similar to BPEL diagrams) with default implementation to call paint() and of cause not final,my
expected use:  usually with most optimization regardless of transform and with additional for extra small pictures

for exporting as image paint may be enough.
Comment 2 Sergey Petrov 2007-07-05 10:53:19 UTC
forget to mention about children of cause corresponding paint/print children methods should be added too, default
implementation may be good the same as in JComponent - set flag and call paint().
Comment 3 David Kaspar 2007-07-24 14:14:07 UTC
The first option is the best since it is minimally affecting API. I would introduce a new enum with these 3 suggested
values. I am just thinking whether these 3 values are suitable for all usages.

One question: Where would be place the "palette" component? From values it looks like the "palette" component should be
visible in VALUE_RENDER_DEFAULT only.
Comment 4 Sergey Petrov 2007-07-24 14:52:09 UTC
Unfortunately, I just realized this issue may not solve "always at 100% zoom" palette requirement so may be will be
useless for palette (but of cause depends on how palette component will be realized). If you are going to introduce own
enumeration you can add more values here which will be more specific, all known for now: GENERAL or
SCENE,OVERVIEW,PRINT,EXPORT,some value for cases which are not fit in four suggested (like UNSPECIFIED or similar).
Anyway it will help not to draw selection border because I can override drawBorder and check if it's
overview,print,export or not before calling super.drawBorder())
Comment 5 David Kaspar 2007-07-24 15:10:11 UTC
Does GENERAL mean VALUE_RENDER_QUALITY? Otherwise I agree.
Using UNSPECIFIED value is not necessary since it is totally unknown/undescribed value, so the Widget would not know
whether and what to paint anyway.
Also there may be added a Printing quality values too e.g. draft vs. final