[scribus-dev] Question about culling area

[Elvis Stansvik]

2011/8/12 Craig Bradney <cbradney at zip.com.au>:
> On 8/12/11 6:47 AM, Elvis Stansvik wrote:
>> 2011/8/11 Elvis Stansvik <elvstone at gmail.com>:
>>> Hi Andreas,
>>>
>>> 2011/8/11 Andreas Vox <andreas.vox at googlemail.com>:
>>>> Hi Elvis!
>>>>
>>>> I introduced the culling area in order to skip objects when drawing just a
>>>> rectangle part of the canvas.
>>>> Culling area = null means no limitation.
>>>>
>>>> The culling area is not a clipping area, that's what PoLine is for. Can't
>>>> you use the PoLine of the cell's
>>>> textframe for your purposes?
>>> Yes, I realize that I've confused myself a bit.
>>>
>>> My confusion comes from thinking that I could somehow paint parts of
>>> the table (cells) in DrawObj_Item(...). This is obviously not possible
>>> as the item needs to repaint itself entirely if requested to do so by
>>> the canvas. Right?
>>>
>>> The problem I'm facing now is that on each key press, I'm now doing:
>>>
>>> m_table->activeCell().textFrame()->handleModeEditKey(event, repeat);
>>> m_table->update();
>>>
>>> This will trigger a re-paint of the entire canvas, and the resulting
>>> lag when typing is quite noticable compared to typing in a regular
>>> text frame.
>>>
>>> I shouldn't have to call m_table->update() right? That will trigger a
>>> lot of things that aren't necessary after a just a key press.
>>>
>>> Just something like
>>>
>>> m_canvas->update(m_canvas->canvasToLocal(m_table->getBoundingRect()));
>>>
>>> should be enough? But for some reason that isn't working; sometimes
>>> the table DrawObj_Item is called and sometimes it's not :/
>>>
>>> Need to do more debugging here.
>> So, after some investigation, the only way I've found reliably works
>> to get my table repainted, without resulting in a repaint of the
>> entire canvas, is:
>>
>> bool repeat;
>> m_table->activeCell().textFrame()->handleModeEditKey(event, repeat);
>> m_canvas->m_viewMode.forceRedraw = true;
>> m_canvas->update(m_canvas->canvasToLocal(m_table->getBoundingRect()));
>>
>> This however implies making my CanvasMode_EditTable a friend of Canvas
>> (to be able to set the forceRedraw). It feels like a hack, but the
>> same thing is done e.g. by the CanvasMode_Normal when selecting items.
>> It seems most of the canvas modes have been made friends of Canvas,
>> for this or other purposes.
>>
>> Without the forceRedraw, the paintEvent of the Canvas will return
>> without painting anything, I guess because of some internal buffering
>> (I even tried with a call to m_canvas->update() without any rectangle
>> parameter).
>>
>> Is there any cleaner solution?
>>
>> Otherwise I will go with this approach for now, since I need to get on
>> with other things.
>>
>> When it comes to the optimization of not having to repaint the entire
>> table on a keystroke, I'll leave that for now. Possibly in the future
>> the table painter could keep a QCache of QImages of cell contents or
>> something like that. But it would need measurements to see if it makes
>> a difference.
>>
>
> If only a start, why not make the forceRedraw protected anyway and add a helper to set it?
> That's how it should be anyway.

Alright. Just wanted to make sure it wasn't considered "bad behavior" to set it.

But then it's just a matter of missing API. I might prepare a patch
later to clean up the API of Canvas and add a setters/getters for
stuff it has in its CanvasViewMode where it makes sense, so that the
canvas modes can hopefully be made enemies of Canvas :)

> But as you say, not much time left.. optimisation can be done later.

Yep.

Elvis