Re: shr using `make-xwidget' incorrectly

[Po Lu <luangruo@yahoo.com>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't see the similarity -- killing the buffer will kill the xwidgets,
> while killing the buffer won't kill the process.  On the other hand,
> deleting text in a buffer won't make the process become unavailable.

Sorry, I meant only processes with associated buffers.  This is how it
would make sense for xwidgets to behave as well.

BTW, it's impossible to cause an xwidget to become unavailable by
deleting text in a buffer: it'll always be available via
get-buffer-xwidgets, and there could be references to the xwidget in
other places.

At present, the only way to kill an xwidget (and to make it potentially
unavailable) is to kill the buffer it's associated with.

So even if we were to introduce an "evaporable" xwidget type, I think it
would only make sense to have it done as part of garbage collection.

>> However, randomly killing xwidgets based on whether or not they are
>> displayed would be undesirable: xwidgets have a lot of state that cannot
>> be reconstituted through recreating them, and creating them takes a long
>> time and a lot of memory.

> There's nothing random about it.  If the caller has marked the widgets
> as being evaporable, then the caller wants those xwidgets to go away if
> they're no longer displayed.

Making xwidgets "evaporable" would cause a lot of overhead, I think.

For example, WebKitGTK may elect to save or delete cached resources, if
the reference count of the context and settings reaches zero.

(Which will always happen if the widget did not have another widget
passed to it as the `related' parameter to make-xwidget, and may happen
regardless.)

Another solution (that doesn't involve attaching xwidgets to the buffer
currently being rendered in) would be have shr attach xwidgets to a
buffer used only for shr to manage xwidgets, and for shr to "recycle"
the xwidgets each time something is rendered.

Please tell me if I'm missing anything, or you have more comments to
make.

Thanks in advance!