Re: SimpleWebKit - Status

[Dr. H. Nikolaus Schaller]

Am 15.03.2007 um 12:49 schrieb Peter Cooper:

> Hi Nikolaus
>
> > Where I have no clear solution is how subresources (e.g. an embedded
> <img>) correctly notify the visual elemens (which is a subclass of
> NSImageCell embedded as an NSTextAttachment in an NSTextView) that  
> their
> content has changed.
>
> My suggestion is to put a placeholder NSTextAttachment (perhaps a  
> "broken
> image" icon as per other browsers) into the NSTextView and defer  
> putting

It is implemented that way and the placeholder already shows...

> the real resource in until the resource has loaded. The image or  
> object
> tag exists in the DOM tree, and your queued loading activity can  
> backfill

This is subissue #1: how is that properly notified through the  
WebDataResource,
WebRepresentation and Web*View protocols and classes to an NSImageCell.

> any references and the correct NSTextAttachment when complete.

Subissue #2 is to really find the *correct* attachment and tell the  
NSTextView to redraw just that one...
Finding the attachment could be easily solved by adding a pointer to  
the DOM element for the <img> tag,
but knowing in which range of the NSTextStorage that attachment  
resides might end up
in sequentially searching attribute runs... Well, not a nice/fast  
solution but might be working.

> > Another unsolved issue is how the loading mechanism should enable the
> CSS parser to handle <style type="text/css">@import "URL"</style>  
> which
> needs to resume parsing onlyy after the subresource data
> > becomes available. Well, parsing could trigger loading of the
> > subresource unless it has already been loaded and stop. Completion of
> the subresource could restart the full CSS parse process.
>
> I'd agree with this. A key user experience optimisation would be  
> creating
> an idea of a "settling time" for the document - mark the document  
> dirty
> and wait for either a small time (0.5 seconds) with no further  
> successful
> resource loads or for the completion (successful or otherwise) of all
> resource loads before triggering a full CSS parse and therefore
> re-rendering.

This brings me to a different approach than the one I currently have  
- let all
that dirty flags be handled within the NSView hierarchy. Then,  
arriving new data
and updates of the DOM elements just set setNeedsDisplay:YES and  
setNeedsLayout:YES
(there is a setNeedsLayout call in the WebDocumentView protocol for  
that purpose).

And the drawRect: method is then called - as soon as the system has time
to do so. If it needs layout, the DOM trees are processed as good as  
possible
to derive the best view that is currently available. If new data  
comes in, the
dirty flags are set again and reparsing/redrawing occurs again.

The difference to my current approach is that in the new one, all  
parsing is
only done as a response to a drawRect request (which might then become
quite time-consuming). This could constrain parsing to only the really
visible parts (*** although we must also parse the invisible parts  
for e.g. JavaScript ***)

Currently, all parsing is done as a repsonse to new data having arrived.
Well not all - the handling of the <frame> and <frameset> tags is  
triggered by the
View hierarchy. Maybe this is the reason why some pages don't display
anything - it appears that they do not get a drawRect: call.

Both approaches have their pros and cons - perhaps we should think about
a mixture?