As discussed in February 2012 [1], we have been deprecating the
webkitNotifications.createHTMLNotification API for almost a year.
According to FeatureObserver, the API is used in only 0.0008% of web
page views, indicating that we have been successful in depreciating
it. I've posted a patch to remo
On Wednesday 23 January 2013, Balazs Kelemen wrote:
> On 01/22/2013 05:14 PM, Zoltan Herczeg wrote:
> >>> Where in WebKit do you experience problems with color conversion?
> >
> > As for me WebKit2 transmits BGRA images, which needs to be converted to
> > RGBA before it is uploaded to a texture on
On 01/22/2013 05:14 PM, Zoltan Herczeg wrote:
Where in WebKit do you experience problems with color conversion?
As for me WebKit2 transmits BGRA images, which needs to be converted to
RGBA before it is uploaded to a texture on GLES 2.0. These conversions
seems computation heavy for certain anima
On Tue, Jan 22, 2013 at 12:39 PM, Allan Sandfeld Jensen
wrote:
> memcpy is heavily optimized for different architectures and even
> subarchitectures. Unless you take the time to write several architecture
> specific BGRA<->RGBA conversions it will never be as fast as memcpy.
>
This is actually v
On Tuesday 22 January 2013, John Bauman wrote:
> Couldn't you just swizzle the value in whatever shader you use? Or you
> could use EXT_texture_format_BGRA or APPLE_texture_format_BGRA.
>
> Also, an optimized BGRA<->RGBA conversion is about the same cost as a
> memcpy, so if you have any m
Couldn't you just swizzle the value in whatever shader you use? Or you
could use EXT_texture_format_BGRA or APPLE_texture_format_BGRA.
Also, an optimized BGRA<->RGBA conversion is about the same cost as a
memcpy, so if you have any memcpys you need to do you could possibly
replace one with
On Tuesday 22 January 2013, Zoltan Herczeg wrote:
> >> Where in WebKit do you experience problems with color conversion?
>
> As for me WebKit2 transmits BGRA images, which needs to be converted to
> RGBA before it is uploaded to a texture on GLES 2.0. These conversions
> seems computation heavy fo
I would say that the right way to go about improving pixel transfer (which is
what you're trying to do, I believe...) is with OS-provided graphics surfaces;
On embedded systems those are usually provided and there are of course
solutions for windows and Mac.
When using graphics surfaces, you don
>> Where in WebKit do you experience problems with color conversion?
As for me WebKit2 transmits BGRA images, which needs to be converted to
RGBA before it is uploaded to a texture on GLES 2.0. These conversions
seems computation heavy for certain animations, and I was wondered whether
do we reall
On Monday 21 January 2013, Benjamin Poulain wrote:
> On Mon, Jan 21, 2013 at 7:00 AM, Zoltan Herczeg wrote:
> > In WebKit both RGBA and BGRA formats are used for different purposes and
> > different platforms in WebKit. Do we have a policy which one we prefer?
> > It would be nice to reduce conver
En 22/01/13 09:52, Maciej Stachowiak escribiu:
>> That'd be awesome, at least an overview document that could help people
>> to understand the whole picture and the main advantages/drawbacks of the
>> selected design.
>
> What topics are you interested in? I could probably write decent explanation
[Replying both Carlos and Sam's mail at once]
Hi,
> El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
> > Hi Mario,
> >
> > The motivation of the change was to reduce the chatter between the
> > WebProcess and UIProcess and reduce the amount of knowledge the
> > UIProcess has about the i
Hi,
Currently WebKit is configured to be compatible with Windows 2000 and
newer Windows versions. After r139514 using InterlockedIncrement64 is
required for int64_t atomicIncrement function to be able to build
WebKit2 for Windows. On 32 bit target this method is supported in XP SP2
and later.
On Jan 22, 2013, at 12:32 AM, "TAMURA, Kent" wrote:
>
>
>> The two mail threads bounce back and forth between Hixie's opinion and
>> yours. Was there a conclusion reached anywhere on what to do with datetime
>> and datetime-local?
>
> We agreed that existing implementations of input[type=date
On Jan 22, 2013, at 12:17 AM, Sergio Villar Senin wrote:
> En 21/01/13 23:07, Maciej Stachowiak escribiu:
>>
>> On Jan 21, 2013, at 11:23 AM, Adam Barth wrote:
>>
>> Thanks, Adam. It's fine to pick up the conversation later, and we're
>> certainly open to iterating beyond what we do first.
>
The two mail threads bounce back and forth between Hixie's opinion and
yours. Was there a conclusion reached anywhere on what to do with datetime
and datetime-local?
We agreed that existing implementations of input[type=datetime] were wrong.
But we have no
conclusion of the type renaming and
En 21/01/13 23:07, Maciej Stachowiak escribiu:
>
> On Jan 21, 2013, at 11:23 AM, Adam Barth wrote:
>
>> Some folks have pointed out to me off thread that I'm coming off as
>> angry and harsh. I would like to apologize for my tone.
>>
>> My goal here is not to obstruct or block your progress on
En 21/01/13 19:39, Zeno Albisser escribiu:
> I was more successful using distcc
> from: http://www.opensource.apple.com/source/distcc/
> This one seemed to work fairly well. The only problem I had was that Qt
> is not actually using xcodebuild.
> Therefore I could not make use of any bonjour servi
El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
> Hi Mario,
>
> The motivation of the change was to reduce the chatter between the
> WebProcess and UIProcess and reduce the amount of knowledge the
> UIProcess has about the internals of the WebProcess. We will also be
> removing the UIP
19 matches
Mail list logo