[webkit-dev] WebKit render tree

[Andy Somogyi]

> On Jun 1, 2016, at 1:37 PM, Myles C. Maxfield <mmaxfield at apple.com> wrote:
> 
> Replies inline.

> Generating a DOM is usually done in JavaScript. I'm curious about the problem you are trying to solve where JavaScript is not sufficient.
> 
> Drawing into an existing window is usually done by inserting a WebView into the view hierarchy of the window. Yet again, I'm interested in why this is not sufficient.

I have the source code of the new language, and a parser/compiler for it written in C++. I’d really hate to have to introduce a new set of languages into the mix. 

The new programming language is designed to be visually edited, hence the need for hit detection. So, a component may be dragged from one region to another. This would trigger an event which would cause one branch of the AST to be pruned, modified and re-attached to another branch. This in turn would trigger a re-gen of the render tree, and eventually a repaint. I've done something very similar in the past where I created a visual computer algebra system. The entire runtime, including AST are written in C++, and it would be nice to connect it to an existing rendering/layout engine, and be able to respond to user events directly in my C++ code. 

I see this as a very dynamic application, and all of the internal logic which is a mix of C and JIT compiled code from the new language needs to interact with both the visual representation, and the physics engine (the Lang is designed for real-time physics simulation). Ideally, I'd like to be able to render a visual representation of a language element to an OpenGL texture, and have this exist in the physics engine. 

However, being as the DOM is publicly available from WebKit in C++ (I think they’re all exposed publicly as pure virtual interfaces), it would be relatively straightforward for me to to compile the new language to target the C++ v-table ABI. 


>> Do you think this would be possible using WebCore as a library and have these custom render tree / dom tree derived objects live in my own library (this is really, really the way I’d prefer to do things), or do you think it would be better to add these objects directly into the WebCore library. 
>> 
> 
> Are you planning on committing any changes to trunk?
> 
> Of course it is ::possible:: to do something like this - it's all software. Are you asking if it's easy to do it? Or the best way to do it

On OSX, I don’t think I’ll have to do any changes at all to WebKit. I’ve got proof of concept working where I create a new RenderElement derived object, and give it a new GraphicsContext. 

However, on Windows, the classes I use from WebKit in my own code would need to be exported via the WEBCORE_EXPORT macro, this would need to be added to each class definition in WebKit. I suppose what I could do is write a quick script which adds this macro to each class that I use as part of my build process. That way, I would not have to touch the upstream webkit source at all. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160601/79a2f30c/attachment.html>