[Dev] wxSynchronizeWidget hints

Fri Oct 21 18:03:02 PDT 2005

How about this:

We already have wxSynchronizeWidget on the widget. Add a new method on 
the widget called something like processNotificationForDirtying, or a 
better name that you choose. All notifications are processed by this 
process routine. You can implement yours on wxCalendar to accumulate 
hints and always dirty the block. I can implement mine on wxTable to 
only dirty the block if it the data that's changed is on the screen. In 
either case SyncronizeWidget is called when it's dirtied.

With this solution you get what you want for Calendar and I get what I 
want for Table.

The irony of your solution is we already have a list of notifcations 
that are maintained by the repository. You take that list and create an 
entirely new list, then process them later. I just process the list once 
at the beginning instead of creating a new list and delaying the processing.

Also, I was curious to know if you ever ignored notifications when 
dragging events on the calendar, editing events or side effects of 
redrawing. I wouldn't be surprised if that would eliminate a bunch of 
unnecessary synchronizeWidget calls. It did for the Table.

Alec Flett wrote:

> John Anderson wrote:
>
>> Blocks and widgets doen't really have a controller. But I don't 
>> really care about that. If you want to make a controller we can do that.
>>
> yes, they do have a controller, although its very rudimentary - its 
> the dirty block mechanism.

Actually there is a lot of "controller" functionallity today and it's 
mostly part of the widget, e.g. clicking on a widgets, dragging, cut, 
copy paste, etc.

>> What I really care about is a performance issue. I want to be able to 
>> process the notifications for my table, ignore changes to items that 
>> aren't visible and ONLY keep a dirty bit if the change affects 
>> something on the screen
>
> So I think what we're really debating about is how the "dirtying" works.
>
> Lets see if I've got you position correct. If everything goes 
> according to what you say:
> 1) when changes come in, you want to flag a block dirty only if the 
> changes affect the given block. Each block can do some pre-processing 
> to determine which changes are relevant.
> 2) when the block is dirtied, the block is resynchronized during the 
> onidle loop
> 3) its up to the block to have saved some sort of hint about what is 
> actually affected during 1), so that when the synchronize happens, 
> they know what to update on screen
>
> Advantages: blocks are only "dirtied" and resynchronized (i.e. 
> synchronizeWidget() is called) only if the notifications caused a 
> relevant change.
> Disadvantage: hints must be processed once when they come in as 
> parameters from notification callbacks (in 1) above) to filter out the 
> relevant hints, or transform the hints into block-specific hints. Then 
> the filtered/transformed hints need to be processed again during 3), 
> when the block has to look through the hints to see what specifically 
> needs to be updated

You need to process the event or the hint in either scheme, so 
processing isn't a disadvantage. However, only the widget know whether 
the notification can be ignored, e.g. doesn't affect the screen. I don't 
need any further hints to be saved. All I need is an bool that causes 
SynchronizeWidget to be called, just like we do today.

>
> Here's what I'm suggesting:
> 1) when changes come in, they are unconditionally accumulated. Blocks 
> are "dirty" if any notifications have come in for that block
> 2) when the "dirty blocks" are synchronized via synchronizeWidget(), 
> the blocks decide if they need to actually rebuild themselves based on 
> the hints that came in.
>
> Advantages: hints are processed in one place - synchronizeWidget(). 
> further, the same hints, in the same format, are used across all 
> blocks. No special code needs to be written to decide which blocks are 
> "dirty" and which aren't.
> Disadvantages: blocks may be considered "dirty" even if 
> synchronizeWidget() ends up doing nothing.
>
>> don't want to accumulate your hints on my block because I'll never 
>> use them. 
>
> That makes no sense, unless you really want to think of them as 
> 'Alec's personal hints' - because its the same exact information, bit 
> for bit, that you'd be processing in your table. I'd just pass them to 
> you in synchronizeWidget, rather than inventing a new way for blocks 
> to intervene in the block-dirtying process.

I think of them as Calendar's hints, since Tables don't need them. What 
we don't agree on is the need for a widget specific function to process 
notifications and a widget specific hints. And I think some widgets, 
e.g. Tables don't event need hints for SynchronizeWidget. Although I 
could see adding them later, but they could very well be widget 
specific, e.g. row and column information..

>
> I'm  suggesting a general mechanism for all blocks rather than 
> requiring each block to figure out how to defer the hints until the 
> synchronize. In my mind, that is simpler, more general, and much 
> easier to maintain.
>
> Alec
>
>> It just makes things way more efficient if we can process 
>> notificaitons as we go instead of storing them to process later. 
>> Surely we can think of a way to do this that works with your MVC view 
>> of CPIA, right?
>>
>> John
>>
>> Alec Flett wrote:
>>
>>> John Anderson wrote:
>>>
>>>> I'd still vote for this hint accumulation to be block specific, 
>>>> e.g. Calendar only. Consider the case where you did some very large 
>>>> operation and didn't get back to the idle loop for a long time. 
>>>> Also, for many blocks, e.g. Table and Calendar most if not all the 
>>>> hint information doesn't need to be kept around until 
>>>> synchronization, it can be processed when the event is handled and 
>>>> never needs to be stored.
>>>
>>> I think that doing that would once again break the MVC paradigm in 
>>> CPIA. It seems like you're saying that for some operations, the 
>>> model should be talking directly to the view, and bypass the 
>>> controller.. the notification mechanism is a pretty key part of the 
>>> controller. The controller (in this case the block synchronizing 
>>> code) needs to ensure that mutations to the model are propagated to 
>>> the view in the order they happen. If the model (blocks) immediately 
>>> updates the view (widgets) in some cases, but notifications are also 
>>> coming in asynchronously via the synchronizeWidget() call, then 
>>> things are more or less guaranteed to get out of sync.
>>>
>>> Plus I'm not really sure why accumulating a list of hints is harmful.
>>>
>>> Maybe you're worried about memory usage? The hints are tuples of 
>>> things like (collection, operation, item) and maybe 1-2 other 
>>> parameters. We're talking about 16-32 bytes per hint - only 16k even 
>>> if tons of events come in. They don't take up a lot of memory, and 
>>> python lists are very efficient.
>>>
>>> Maybe you're worried that if 10,000 hints are passed in via 
>>> wxSynchronizeWidget() that the widget in question would waste a lot 
>>> of time processing 10,000 hints? I feel like that is an optimization 
>>> we can make on a per-widget level - if 10,000 hints come in, then we 
>>> just blow away the widget and rebuild it from the block data. But we 
>>> make that call when we hit performance limits - we don't prematurely 
>>> optimize that now.
>>>
>>> Alec
>>>
>>>------------------------------------------------------------------------
>>>
>>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>>Open Source Applications Foundation "Dev" mailing list
>>>http://lists.osafoundation.org/mailman/listinfo/dev
>>>  
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20051021/7684dc6d/attachment.html