[webkit-dev] Adding CSS blending to WebKit
All, I'm planning on adding CSS blending to WebKit: https://bugs.webkit.org/show_bug.cgi?id=91908 We already have a working prototype and I will bring it over as a couple of patches. We did a couple of write-ups on this feature: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/ http://blogs.adobe.com/webplatform/2012/07/17/new-blending-features-in-css/ http://html.adobe.com/webstandards/csscompositing/ This is my first time contributing so let me know if there is another process I should follow. Rik Cabanier Adobe Systems ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Question about embedding webkit
Hi, On Fri, Jul 20, 2012 at 11:05 AM, wrote: > I tried to replace href="/foo" by href="./foo" and so on but it doesn't > solve anything, so my question is how can I run > those files inside an application that uses webkit ? Do I also need to > integrate inside my application a small http server ? > Is there any other solution you can think of ? You shouldn't need to run a local server unless you have some kind of server-side logic that is part of the function of this program. You will load the main "page" of your application using something like the IWebFrame::loadHTMLString interface. The method asks for the HTML to render (which will include your various relative path includes), and a "base URL" argument that allows you to set where the effective "root" of your application lives on the local machine. Check the WebKit .Net documentation and see where it provides its mechanism for setting the base URL. It is internally calling one of the IWebFrame interface calls, but I am not sure which one. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Question about embedding webkit
Hi, I am not sure this is the right place to ask but I suppose you may have an idea of the answer. I would like to embedd inside a native application some source files that are usually run inside a google chrome extension. My problem is that when I try to open those files locally using chrome for instance, base url are wrong and it cannot find images, scripts, ... I tried to replace href="/foo" by href="./foo" and so on but it doesn't solve anything, so my question is how can I run those files inside an application that uses webkit ? Do I also need to integrate inside my application a small http server ? Is there any other solution you can think of ? PS : My application is written in C# and uses a .net wrapper for the webkit dll. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 11:48 AM, Brady Eidson wrote:
> On Jul 20, 2012, at 7:53 AM, Shezan Baig wrote:
>> And because I'm in the middle of debugging a particular issue, I don't
>> really want to create a new type that wraps up those (potentially
>> unrelated) variables, just in order to create an overloaded "debug()"
>> function that does the pretty printing.
>
> I'm not quite sure what your point is here.
>
> - If you mean you don't want to be hassled by added a new template for a
> super long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when
> the built in utility only supports up through k - then that seems somewhat
> silly as doing so would be simple and mechanical.
>
> - If you mean you don't want to be hassled to add a new overload for the type
> you'd like to print, then you'd still have to add a new operator << overload
> for that type if it didn't already exist.
>
> - If you mean you don't think that debug() statements could be broken up in
> to multiple lines, of course they can.
>
> debug("Selectively printing variables:";
>if (isSet(someVar1))
> debug("someVar1 = ", someVar1);
>if (isSet(someVar2))
> debug("someVar1 = ", someVar1);
>if (someVector.size())
> debug(" someVector.items = ", someVector);
> debug("\n");
>
Yes, this one is pretty much what I meant. My example was a bit
simplified, but I was thinking more along the lines that the code
around the debug() statements could be expensive, for example,
calculating some value from multiple sources and printing the final
result. Within the context of a single function, it might not make
sense to create a separate function that is responsible for
calculating those values, especially if the variables involved are not
typically related.
But your points about readability and such are understood.
Thanks,
-shez-
> Also notice it would be easy to templatize a debug() override to handle the
> pretty-printing of the vector directly, in addition to other POD and
> non-class types.
>
> Even without the vector enhancement, this version is simple easier on my eyes
> as it's not at odds with the entire rest of our code base.
>
> ~Brady
>
>> -shez-
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 20, 2012, at 7:53 AM, Shezan Baig wrote:
> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev wrote:
>>
>> 19.07.2012, 22:20, "Filip Pizlo" :
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>>> baz " << c << endl;
>>> This is 8 procedure calls and three string constants. This code will be
>>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>>> enable such debug statements in release builds both due to fears concerning
>>> unnecessary increases in binary size, and unnecessary increases in compile
>>> times.
>>
>> Well, if all << operators are inline, it will be optimized. You also don't
>> have to add endl, because "thingy" can add '\n' and flush buffer at the end
>> by default (like qDebug does)
>>
>
>
> Also, if "START_THINGY" and "END_THINGY" are defined as:
>
> #define START_THINGY if (enableDebug) { thingy
> #define END_THINGY<< endl; }
>
> Then a statement like:
>
> START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
> << b << " baz " << c << END_THINGY;
>
> will all be wrapped up within an "if (enableDebug)" condition, which
> we would only turn on when we need the log output, so the cost of the
> streaming/printing can be virtually eliminated even if we decide to
> land the code.
I see in your followup you realized we could further wrap these in #ifndef
NDEBUG blocks. That's all good and well until someone takes a block like...
> This also allows us to do more complex things like:
>
> START_THINGY << "Selectively printing variables:";
>if (isSet(someVar1))
>thingy << " someVar1 = '" << someVar1 << "'";
>if (isSet(someVar2))
>thingy << " someVar2 = '" << someVar2 << "'";
>
>if (someArray.length()) {
>thingy << " someArray.items = [";
>for (int i = 0; i < someArray.length(); ++i) {
>thingy << someArray[i] << ", ";
>}
>thingy << "]";
>}
> thingy << END_THINGY;
…this and tries to add their own internal #ifndef DEBUG blocks within the
statement. For this reason we tend to keep the "automatically #ifdef NDEBUG
protected" utilities like LOG and ASSERT limited to a single statement.
In general this is voluminous code we'd probably not want landed the same way
we like dataLog() and LOG() statements to be landed. But a specific reason we
wouldn't want it landed is that It's not at all obvious to a casual observer
that this entire block is meant to be debug only.
> And because I'm in the middle of debugging a particular issue, I don't
> really want to create a new type that wraps up those (potentially
> unrelated) variables, just in order to create an overloaded "debug()"
> function that does the pretty printing.
I'm not quite sure what your point is here.
- If you mean you don't want to be hassled by added a new template for a super
long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when the built
in utility only supports up through k - then that seems somewhat silly as doing
so would be simple and mechanical.
- If you mean you don't want to be hassled to add a new overload for the type
you'd like to print, then you'd still have to add a new operator << overload
for that type if it didn't already exist.
- If you mean you don't think that debug() statements could be broken up in to
multiple lines, of course they can.
debug("Selectively printing variables:";
if (isSet(someVar1))
debug("someVar1 = ", someVar1);
if (isSet(someVar2))
debug("someVar1 = ", someVar1);
if (someVector.size())
debug(" someVector.items = ", someVector);
debug("\n");
Also notice it would be easy to templatize a debug() override to handle the
pretty-printing of the vector directly, in addition to other POD and non-class
types.
Even without the vector enhancement, this version is simple easier on my eyes
as it's not at odds with the entire rest of our code base.
~Brady
> -shez-
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 10:53 AM, Shezan Baig wrote:
> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev wrote:
>>
>> 19.07.2012, 22:20, "Filip Pizlo" :
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>>> baz " << c << endl;
>>> This is 8 procedure calls and three string constants. This code will be
>>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>>> enable such debug statements in release builds both due to fears concerning
>>> unnecessary increases in binary size, and unnecessary increases in compile
>>> times.
>>
>> Well, if all << operators are inline, it will be optimized. You also don't
>> have to add endl, because "thingy" can add '\n' and flush buffer at the end
>> by default (like qDebug does)
>>
>
>
> Also, if "START_THINGY" and "END_THINGY" are defined as:
>
> #define START_THINGY if (enableDebug) { thingy
> #define END_THINGY<< endl; }
>
And we could also wrap these macros with #ifdef ENABLE_THINGY, so even
the compile-time cost is eliminated if we don't want to include thingy
output in our build.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev wrote:
>
> 19.07.2012, 22:20, "Filip Pizlo" :
>> Now consider the stream form:
>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>> baz " << c << endl;
>> This is 8 procedure calls and three string constants. This code will be
>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>> enable such debug statements in release builds both due to fears concerning
>> unnecessary increases in binary size, and unnecessary increases in compile
>> times.
>
> Well, if all << operators are inline, it will be optimized. You also don't
> have to add endl, because "thingy" can add '\n' and flush buffer at the end
> by default (like qDebug does)
>
Also, if "START_THINGY" and "END_THINGY" are defined as:
#define START_THINGY if (enableDebug) { thingy
#define END_THINGY<< endl; }
Then a statement like:
START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
<< b << " baz " << c << END_THINGY;
will all be wrapped up within an "if (enableDebug)" condition, which
we would only turn on when we need the log output, so the cost of the
streaming/printing can be virtually eliminated even if we decide to
land the code.
This also allows us to do more complex things like:
START_THINGY << "Selectively printing variables:";
if (isSet(someVar1))
thingy << " someVar1 = '" << someVar1 << "'";
if (isSet(someVar2))
thingy << " someVar2 = '" << someVar2 << "'";
if (someArray.length()) {
thingy << " someArray.items = [";
for (int i = 0; i < someArray.length(); ++i) {
thingy << someArray[i] << ", ";
}
thingy << "]";
}
thingy << END_THINGY;
Often when I'm debugging something, I really want to selectively craft
the log message so that I only need to see the variables I'm
interested in, depending on the state of the program *at that time*.
This reduces the clutter in the log message, and since this whole
block is wrapped within "if (enableDebug)", the cost of any additional
work used to generate the log message is completely eliminated if
debug mode is disabled.
And because I'm in the middle of debugging a particular issue, I don't
really want to create a new type that wraps up those (potentially
unrelated) variables, just in order to create an overloaded "debug()"
function that does the pretty printing.
-shez-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
19.07.2012, 22:20, "Filip Pizlo" : > Now consider the stream form: > thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " > baz " << c << endl; > This is 8 procedure calls and three string constants. This code will be > somewhere around 8 times fatter. Hence, you will be less likely to want to > enable such debug statements in release builds both due to fears concerning > unnecessary increases in binary size, and unnecessary increases in compile > times. Well, if all << operators are inline, it will be optimized. You also don't have to add endl, because "thingy" can add '\n' and flush buffer at the end by default (like qDebug does) -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
