Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Sam Weinig]

Since it is confusing to me (and may be to others), perhaps a different name 
than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, 
ENABLE_NEW_FLEXBOX?

-Sam
  
On Jun 10, 2011, at 2:42 PM, David Hyatt wrote:

> Just so people know, it was my recommendation that they just start with a new 
> renderer and implementation.
> 
> Some other recommendations I would make here (apologies if they have been 
> implemented already):
> 
> (1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
> e.g., RenderDeprecatedFlexibleBox.
> 
> (2) The old flexbox was never patched for vertical writing modes. Please make 
> sure when you build the new renderer from the ground up that you take this 
> into account.
> 
> (3) Please consult with rendering experts for any changes you have to make to 
> base classes, especially RenderBlock and RenderBox. We may be able to help 
> simplify some of that code, especially compared to the old flexbox.
> 
> (4) Use the old flexbox code as a rough guide, but be aware of its issues, 
> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
> think some of the bugs you tried to fix already should inform this somewhat.
> 
> Definitely keep rendering experts in the loop on this and have fun 
> implementing!
> 
> Dave
> 
> 
>> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
>> 
>>> Hi webkit-dev,
>>> 
>>> I wanted to let you know that Ojan and I plan to add flexbox layout support 
>>> to WebCore.  WebCore already supports an older flexbox implementation 
>>> (display: box), but the new spec is designed to be easier for developers to 
>>> understand and more powerful.  The old flexbox will still remain in WebCore 
>>> since none of the CSS properties overlap with the new flexbox spec.  The 
>>> spec can be found at: http://www.w3.org/TR/css3-flexbox/ 
>>> (http://dev.w3.org/csswg/css3-flexbox/)
>>> 
>>> This support will be behind the ENABLE_FLEXBOX feature define 
>>> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
>>> tracking the feature's development 
>>> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
>>> eventually be enabled by all ports.
>>> 
>>> I am ready to setup a buildbot for tracking the compile and flexbox related 
>>> layout tests.  Should I go ahead and get this added to build.webkit.org's 
>>> waterfall?
>>> 
>>> Thanks,
>>> Tony
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[David Hyatt]

Just so people know, it was my recommendation that they just start with a new 
renderer and implementation.

Some other recommendations I would make here (apologies if they have been 
implemented already):

(1) Rename the current RenderFlexibleBox to put "deprecated" into the name, 
e.g., RenderDeprecatedFlexibleBox.

(2) The old flexbox was never patched for vertical writing modes. Please make 
sure when you build the new renderer from the ground up that you take this into 
account.

(3) Please consult with rendering experts for any changes you have to make to 
base classes, especially RenderBlock and RenderBox. We may be able to help 
simplify some of that code, especially compared to the old flexbox.

(4) Use the old flexbox code as a rough guide, but be aware of its issues, 
e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I 
think some of the bugs you tried to fix already should inform this somewhat.

Definitely keep rendering experts in the loop on this and have fun implementing!

Dave


> On Jun 8, 2011, at 10:57 AM, Tony Chang wrote:
> 
>> Hi webkit-dev,
>> 
>> I wanted to let you know that Ojan and I plan to add flexbox layout support 
>> to WebCore.  WebCore already supports an older flexbox implementation 
>> (display: box), but the new spec is designed to be easier for developers to 
>> understand and more powerful.  The old flexbox will still remain in WebCore 
>> since none of the CSS properties overlap with the new flexbox spec.  The 
>> spec can be found at: http://www.w3.org/TR/css3-flexbox/ 
>> (http://dev.w3.org/csswg/css3-flexbox/)
>> 
>> This support will be behind the ENABLE_FLEXBOX feature define 
>> (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug 
>> tracking the feature's development 
>> (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect this feature to 
>> eventually be enabled by all ports.
>> 
>> I am ready to setup a buildbot for tracking the compile and flexbox related 
>> layout tests.  Should I go ahead and get this added to build.webkit.org's 
>> waterfall?
>> 
>> Thanks,
>> Tony
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] converting VARIANT array to ArrayBuffer

[Anthony Johnson]

Hi webkit-dev,
I'm new to webkit, so still learning, but I'm trying to fill in WebKitLib's
WebScriptObject::callWebScriptMethod() functionality in c++ for windows. In
order to do that, I need to convert COM-style VARIANT arguments into
javascript values. I've got the basic types working, but I'm getting hung up
on converting VARIANT arrays. In the end I would like the code to convert a
VARIANT array of primitives into its corresponding ArrayBufferView, and a
VARIANT array of VARIANTs into a javascript array type. Haven't got to the
latter yet, but on the former I can't seem to create an ArrayBuffer or
ArrayBufferView from within WebScriptObject's scope. Here's what I've done.
To create an Int32Array, I first tried including
, but apparently the #include <> root
directory for building WebKitLib is actually the Webcore directory in the
distribution folder, and Int32Array.h is not in the distribution folder. So
instead, I tried doing a #include "../../WebCore/html/canvas/Int32Array.h".
That worked (although I bet that's not really kosher). So, once I got that
to work, I then needed to convert the Int32Array into a JSValue. So I used
the toJS() function defined at line 72 of .
That compiled correctly, but then I got linker errors saying that toJS was
an unresolved external symbol. I could probably keep pounding away down this
road until it works, but I figure there's got to be a better way that's
already set up. Could someone show me the right way?
Thanks,
Anthony Johnson
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DumpRenderTree for the EFL port :)

[Eric Seidel]

I looked through all the patches.

There is a general trouble of that the code is written in very-old
C-style yet uses a c++ compiler.  I think this will come back to haunt
you in the future as more people try to work on the code.

I suspect that there are many memory leaks in the code as written,
mostly due to the lack of smart pointers.

I'm ready to r+ the patches re-posted with some modern c++ usage.

I'm also OK with someone else approving them if EFL style requires
this ancient-C (and bad memory-management) look.

-eric

On Fri, Jun 10, 2011 at 12:10 PM, Eric Seidel  wrote:
> This is *so* importnat to the long-term health of your port.
>
> Congrats!  I'm happy to review what I can and will look through them now.
>
> -eric
>
> On Fri, Jun 10, 2011 at 12:02 PM, Leandro Pereira
>  wrote:
>> Hey,
>>
>> At last, the EFL port of WebKit got a DumpRenderTree implementation!
>> We're still working on ironing out a lot of bugs found by some of the
>> LayoutTests, but the DRT (and ImageDiff) code has been submitted to
>> Bugzilla. It would be awesome if anyone could help reviewing these
>> patches.
>>
>> DumpRenderTree patches:
>> https://bugs.webkit.org/show_bug.cgi?id=62034
>> https://bugs.webkit.org/show_bug.cgi?id=61974
>> https://bugs.webkit.org/show_bug.cgi?id=61962
>> https://bugs.webkit.org/show_bug.cgi?id=61958
>>
>> ImageDiff patch:
>> https://bugs.webkit.org/show_bug.cgi?id=61942
>>
>> Thanks,
>>   Leandro
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DumpRenderTree for the EFL port :)

[Eric Seidel]

This is *so* importnat to the long-term health of your port.

Congrats!  I'm happy to review what I can and will look through them now.

-eric

On Fri, Jun 10, 2011 at 12:02 PM, Leandro Pereira
 wrote:
> Hey,
>
> At last, the EFL port of WebKit got a DumpRenderTree implementation!
> We're still working on ironing out a lot of bugs found by some of the
> LayoutTests, but the DRT (and ImageDiff) code has been submitted to
> Bugzilla. It would be awesome if anyone could help reviewing these
> patches.
>
> DumpRenderTree patches:
> https://bugs.webkit.org/show_bug.cgi?id=62034
> https://bugs.webkit.org/show_bug.cgi?id=61974
> https://bugs.webkit.org/show_bug.cgi?id=61962
> https://bugs.webkit.org/show_bug.cgi?id=61958
>
> ImageDiff patch:
> https://bugs.webkit.org/show_bug.cgi?id=61942
>
> Thanks,
>   Leandro
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] DumpRenderTree for the EFL port :)

[Leandro Pereira]

Hey,

At last, the EFL port of WebKit got a DumpRenderTree implementation!
We're still working on ironing out a lot of bugs found by some of the
LayoutTests, but the DRT (and ImageDiff) code has been submitted to
Bugzilla. It would be awesome if anyone could help reviewing these
patches.

DumpRenderTree patches:
https://bugs.webkit.org/show_bug.cgi?id=62034
https://bugs.webkit.org/show_bug.cgi?id=61974
https://bugs.webkit.org/show_bug.cgi?id=61962
https://bugs.webkit.org/show_bug.cgi?id=61958

ImageDiff patch:
https://bugs.webkit.org/show_bug.cgi?id=61942

Thanks,
   Leandro
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Ojan Vafai]

On Fri, Jun 10, 2011 at 10:14 AM, Tony Chang  wrote:

> On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak  wrote:
>
>> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>>
>> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:
>>
>>> If the issue is the syntax for describing flexing, perhaps the spec
>>> should be written in a backwards compatible way, that supports both the new
>>> syntax and the old syntax, but the underlying implementation can remain.
>>>
>>
>> The new syntax describes a superset of features provided by the old
>> syntax.  I think it's possible to implement the old flexbox on top of the
>> new flexbox implementation and that seems like a worthwhile goal, but it'll
>> probably easier to see the similarities for refactoring after the code has
>> been written.
>>
>> If it's a superset then I would much prefer to see the old code
>> incrementally enhanced to support the extended features and new syntax, then
>> to first rewrite from scratch and merge. Maybe the right step 1 is
>> refactoring and cleaning up the old code. Rewriting from scratch throws away
>> accumulated knowledge, and in cases where we have to keep the old
>> implementation too, bloats the code.
>>
>
> The decision to start from scratch was based on a recommendation by Hyatt
> on IRC to just rename the old implementation (to RenderDeprecatedFlexibleBox
> or something) and make a new implementation of RenderFlexibleBox.
>

Hyatt should probably chime in here, but on IRC he seemed to think that the
old RenderFlexibleBox was a bad design and needed a complete rewrite
anyways.

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Tony Chang]

On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak  wrote:
>
> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>
> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig  wrote:
>
>> If the issue is the syntax for describing flexing, perhaps the spec should
>> be written in a backwards compatible way, that supports both the new syntax
>> and the old syntax, but the underlying implementation can remain.
>>
>
> The new syntax describes a superset of features provided by the old syntax.
>  I think it's possible to implement the old flexbox on top of the new
> flexbox implementation and that seems like a worthwhile goal, but it'll
> probably easier to see the similarities for refactoring after the code has
> been written.
>
> If it's a superset then I would much prefer to see the old code
> incrementally enhanced to support the extended features and new syntax, then
> to first rewrite from scratch and merge. Maybe the right step 1 is
> refactoring and cleaning up the old code. Rewriting from scratch throws away
> accumulated knowledge, and in cases where we have to keep the old
> implementation too, bloats the code.
>

The decision to start from scratch was based on a recommendation by Hyatt on
IRC to just rename the old implementation (to RenderDeprecatedFlexibleBox or
something) and make a new implementation of RenderFlexibleBox.

I can try to incrementally improve the existing code, but I think that'll
hinder the design of the new code.  For example, when writing the new code,
I plan on adding the CSS properties flex-direction, flex-order, and
flex-pack incrementally (separate patches for each, maybe multiple for
flex-direction).  Since the old flexbox code has slightly different
variations of these already implemented, I would have to run the code for
them on the old code path but not the new code path.  While I think this is
technically possible, I think it'll be tricky to get right.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] question wrt knowing if some text or graphics will be drawn on next webkit render Thursday, June 9, 2011 10:11 AM From:

[D.J. Barrow]

Hi Simon,
We found the other problem in EWebLauncher regarding the
screen being blank while loading a new page.
When we were receiving a on_viewport,changed message
from Webkit on loading a new page this was calling
WebCore::FrameView::forceLayout on the page
so despite having no data the stupid thing
thought it had done a valid firstlayout of the page.


D.J. Barrow Linux kernel developer
email: dj_bar...@ariasoft.ie
Mobile Ireland: +353-86-1715438
www.travelsmart.ie, everyones favourite carpool website, works beautifully on 
the apple iphone
www.warehog.com, & you thought ebay was good
www.ariasoft.ie, See my GPL contributions


--- On Thu, 6/9/11, Simon Fraser  wrote:

> From: Simon Fraser 
> Subject: Re: [webkit-dev] question wrt knowing if some text or graphics will 
> be drawn on next webkit render Thursday, June 9, 2011 10:11 AM From:
> To: dj_bar...@ariasoft.ie
> Cc: webkit-dev@lists.webkit.org
> Date: Thursday, June 9, 2011, 2:57 PM
> On Jun 9, 2011, at 2:29 AM, D.J.
> Barrow wrote:
> 
> > Hi there,
> > I'm making enhancements to EWebLauncher & the ewk
> backend
> > on a low end mips box.
> > A colleague of mine is disappointed that the screen
> > goes blank for several seconds before displaying
> > more complex pages like bbc news.#
> > 
> > What we would like to be able to do is leave the old
> > page on the screen until there is some text or
> graphics
> > on the new page to be displayed.
> > 
> > We are not using WebKit2.
> > WebCore::FrameView::layout getting called only
> > invalidates stuff on the screen & doesn't
> gaurantee
> > that WebCore::FrameView::paintContents
> > has anything to draw other than blank the screen
> > in the next redraw session
> 
> WebKit1 on Mac has some logic for this.
> 
> WebFrameLoaderClient::provisionalLoadStarted() turns off
> drawing, and it
> gets turned back on via
> WebFrameLoaderClient::dispatchDidFirstLayout()
> and WebFrameLoaderClient::frameLoadCompleted(). This leaves
> stale
> pixels on the screen while the new page is early in the
> loading process,
> preventing a flash between pages.
> 
> Simon
> 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Building WebKit with Intel Compiler icc

[Konstantin Tokarev]

09.06.2011, 23:05, cb07...@qmul.ac.uk:
> Hello,
> I don't know if this is the right forum to ask this question. If it isn't I'd 
> appreciate any pointers to where I should be asking this:
>
> I would like to build WebKit with Intel Compiler (ICC) and was wondering if 
> this has been already done or if anyone has pointers on what would be the 
> easiest way to do it.
>
> Thanks in advance for any help you can provide me with,

Once I've successfully built Qt 4.6.3 with included QtWebKit version using icc 
11 for x86_64. But 32-bit version failed to compile.

Situation may be quite different now.


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] parallel painting

[Zoltan Herczeg]

Hi,

wow, your use case is really interesting. I have never thought about that.
Yeah, that would be a simple extension to the parallel painting system,
you could replay the commands anywhere, any times. It is basically a
vector graphics representation of the screen, you could scale it up.

Actually I am really happy that those techinques we were working on
eventually attracting others. We were the first one who played with
parallelization, SIMD instruction sets, and their usage is growing in
WebKit now. Devices (people) actually use them! It seems playing with new
approaches (even radical changes) are never a waste of time. We could
learn a lot from them.

Regards,
Zoltan

> On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote:
>>
>> Android uses a retain mode rendering approach as well; where paint
>> operations are recorded on a WebCore thread and painting is actually
>> done on the UI thread. It isn't necessarily the best approach. But I
>> suppose it depends the platform whether or not there is much to gain.
>> You still need to worry about synchronization.
> ...
>> On 6 April 2010 03:24, Eric Seidel > > wrote:
>>
>> Parallel painting would only be useful if the graphics layer is
>> incredibly slow.  In most WebKit ports we do not see very much time
>>
> ...
>>
>> On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg
>> mailto:zherc...@inf.u-szeged.hu>> wrote:
>> > Hi,
>> >
>> > I am working on a parallel painting feature for WebKit (bug id:
>> 36883).
>> > Basically it records the painting commands on the main thread,
>> and replay
>> > them on a painting thread. The gain would be that the recording
>> operation
>>
>
> Is this something that could be used to "duplicate" painting commands?
>
> I'm very interested in enabling secondary painting contexts,
> to enable better representation of Zoom, and other common assistive
> techniques.
>
> Example:
> If the recording is used, prefixed with scale and crop, a user could be
> presented with
> a crisp and clear magnification of a focused region or other sub-region.
>
> Such techniques could also be useful for remote viewing, via
> serialization,
> and for efficient screen dumps [assuming the render works, of course].
>
> It'd be great, if some time, secondary user agents, like the popular
> ZoomText Magnifier,
> were able to interact with WebKit and request regions to be painted at a
> higher resolution,
> so as to display the magnified image at native resolution.
>
> Does that make sense? Is that something that this technique might
> eventually provide?
>
> I suspect that screen mirroring and other forms of screen sharing will
> become more common
> in use, as more and more physical screens become common in our common
> lives.
>
> -Charles
>

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev