Bug 35936 - [EFL] Add ewk_view_single.c to WK/efl/ewk
: [EFL] Add ewk_view_single.c to WK/efl/ewk
Status: RESOLVED FIXED
: WebKit
Platform
: 528+ (Nightly build)
: Other Linux
: P2 Enhancement
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2010-03-09 11:41 PST by
Modified: 2010-03-13 01:54 PST (History)


Attachments
Add ewk_view_single to WK/efl/ewk (19.24 KB, patch)
2010-03-09 11:42 PST, Leandro Pereira
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-03-09 11:41:41 PST
+++ This bug was initially created as a clone of Bug #35059 +++

The attached patch adds ewk_view_single.c to WebKit/efl/ewk.
------- Comment #1 From 2010-03-09 11:42:21 PST -------
Created an attachment (id=50336) [details]
Add ewk_view_single to WK/efl/ewk
------- Comment #2 From 2010-03-12 12:05:09 PST -------
(From update of attachment 50336 [details])
The coding style differs from that of WebKit, but in the WebKit/eft you can use the EFL C style if that is what you'ld like.

Personally I think you could benefit from more descriptive variable names than oh (height?) etc.

I see that you implement some kind of tiling. It would be nice to use the new tiling system in WebCore if possible. Doing that you will be able to use the upcoming 'paint in another thread' patch.
------- Comment #3 From 2010-03-12 12:37:22 PST -------
Hi Kenneth,

Yes, we'd like to keep EFL's coding style in the port-specific part under WebKit/efl as we expect more EFL hackers will work with it and it's what they are used... we should have very few bits of C++ and WebCore access there, so it does make sense.

About the variables, it is part of the EFL coding standards. It may make more sense to have objectHeight for you, but we're used to oh... Our whole SVN is about these, so it's commonly named variables. Yeah, there could be endless discussion about this, but if possible we'd like to keep it like that (otherwise any patch by Rasterman we'll have to be redone!)

There is no tiling backing store here. We do have one, but it's not being upstreamed at this point due various issues, maybe it will go later.  The tiling you see here is a rectangle splitter/merger, the same as used in Evas. It's duty is to get a list of rectangles, check if they are overlapping and if so split into multiple rectangles, if there are nearby rectangles to be merged, they are. And this also accounts a fuzzy factor that would allow merging 2 rectangles even if they don't match an edge perfectly, painting more area in trade of performance as if the number of rectangles grows too much, clipping will hurt performance.
------- Comment #4 From 2010-03-12 12:44:22 PST -------
(In reply to comment #3)
> Hi Kenneth,
> 
> Yes, we'd like to keep EFL's coding style in the port-specific part under
> WebKit/efl as we expect more EFL hackers will work with it and it's what they
> are used... we should have very few bits of C++ and WebCore access there, so it
> does make sense.

OK, sounds good to me.

> About the variables, it is part of the EFL coding standards. It may make more
> sense to have objectHeight for you, but we're used to oh... Our whole SVN is
> about these, so it's commonly named variables. Yeah, there could be endless
> discussion about this, but if possible we'd like to keep it like that
> (otherwise any patch by Rasterman we'll have to be redone!)

Yes, if that is what you are used to and as this part of WebKit is only used by you, I think you should keep 'oh' etc. 

> There is no tiling backing store here. 

I believe that the WebCore one landed some time ago with a Qt implementation. I'm a bit behind on bugzilla emails so I might be wrong.

> We do have one, but it's not being
> upstreamed at this point due various issues, maybe it will go later.  The
> tiling you see here is a rectangle splitter/merger, the same as used in Evas.
> It's duty is to get a list of rectangles, check if they are overlapping and if
> so split into multiple rectangles, if there are nearby rectangles to be merged,
> they are. And this also accounts a fuzzy factor that would allow merging 2
> rectangles even if they don't match an edge perfectly, painting more area in
> trade of performance as if the number of rectangles grows too much, clipping
> will hurt performance.

OK, sounds good.
------- Comment #5 From 2010-03-13 01:54:51 PST -------
(From update of attachment 50336 [details])
Clearing flags on attachment: 50336

Committed r55957: <http://trac.webkit.org/changeset/55957>
------- Comment #6 From 2010-03-13 01:54:56 PST -------
All reviewed patches have been landed.  Closing bug.