<Swing Dev> <AWT Dev> Inefficiencies with custom TableCellRenderer and Applets

[Clemens Eisserer]

Hi Artem,

Sorry, I haven't been monitoring this discussion the last two weeks or so.
Thanks a lot for looking into it, and for filing the bug.

Clemens

2008/5/23 Artem Ananiev <Artem.Ananiev at sun.com>:
>
> Artem Ananiev wrote:
>>
>> Shannon Hickey wrote:
>>>
>>> Clemens Eisserer wrote:
>>>>
>>>> Hi,
>>>>
>>>> I've created a library which has to use custom TableCellRenderers for
>>>> its tables.
>>>> I experienced a large performance difference between running my
>>>> application as Application inside an JFrame and as an JApplet.
>>>> Parented inside of the JFrame scrolling the table was smooth, however
>>>> scrolling inside the applet was slow, especially if the mouse is over
>>>> the table while scrolling.
>>>>
>>>> I did some profiling with netbeans-profiler and found the root-cause:
>>>>
>>>> BasicTableUI.paintCell->CellRendererPane.paintComponent->Container.validate->Component.updateCursorImmediatly->GlobalCursorManager.updateCursorImmediatly()->_updateCursor....
>>>>
>>>> The updateCursorImmediatly was called both times about 16.000 times,
>>>> with JFrame it consumed 22% of the cycles which is already
>>>> inefficient.
>>>> As JApplet it calls into getLocationOnScreen() which calls down till
>>>> XBaseWindow.toOtherWindow even slower which is about as slow as
>>>> updating the Cursor itself, so as applet it consumes 48% of all EDT
>>>> cycles.
>>
>> What a sad story... I will file a bug against AWT about this problem.
>
> The bug ID is 6706534 - it must be visible in the web in a couple of days.
>
> Artem
>
>>>> The DefaultTableCellRenderer simply overrides validate with an empty
>>>> method, therefor no such calls are done.
>>>> But why does CellRendererPane.paintComponent() call validate at all?
>>>
>>> CellRendererPain takes an argument that dictates whether or not it
>>> validates. In most cases it's told to validate by the caller since the
>>> renderer may need to do layout on its children.
>>>
>>> I suggest you override validate() on your custom renderer to do nothing,
>>> the same way the DefaultTableCellRenderer does.
>>>
>>>> If it cannot be avoided, is there no way to cache stuff in
>>>> XBaseWindow.toOtherWindow at all?
>>
>> We have some kind of caching for this call, however in the case of applets
>> (embedded frames) it doesn't work very well...
>>
>> Artem
>>
>>> You'll have to ask the AWT team about this. I've CC'd them.
>>>
>>> Shannon
>>>
>>>>
>>>> Thanks, lg Clemens
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Very simple TableCellRenderer which triggers the slowness:
>>>>      JLabel renderer = new JLabel();
>>>>      public Component getTableCellRendererComponent(JTable table, Object
>>>> value,
>>>>          boolean isSelected, boolean hasFocus, int row, int column) {
>>>>         renderer.setText((String)value);
>>>>         renderer.setOpaque(true);
>>>>        return renderer;
>>>>      }
>>>
>