When I apply WebKit transform change to the dom style attr, for instance:
Change from:
<div style="-webkit-transform: translateZ(0px) translateX(-9.609375%); "</div>
To:
<div style="-webkit-transform: translateZ(0px) translateX(-10.609375%); "</div>
Is this rendering change hardware accelerated? If it's supported in the browser, of course.
Webkit browsers will use hardware acceleration for 3D transforms, but not 2D transforms.
Here's a post that explains it: http://creativejs.com/2011/12/day-2-gpu-accelerate-your-dom-elements/
So yes, including translateZ(0) should force hardware acceleration for supported browsers.
As a side note, using 3D transforms on Android 2 devices doesn't work, so you'll have to stick with 2D.
Related
I'm currently adapting my personal engine to Vulkan and I want to reimplement transparent windows, which I already had with OpenGL.
I thought that all I need to do is to select the correct color format ( with alpha channel ) and to set the compositeAlpha property of VkSwapchainCreateInfoKHRto VK_COMPOSITE_ALPHA_POST_MULTIPLIED_BIT_KHR.
However clearing the window with a full transparent color doesn't provide the expected results. It's fully opaque.
Of course my window system, which didn't change since I had OpenGL, supports it and when I just disable the rendering I also can't click through at the supposed position of the window, this tells me that it's there.
Are there any other required changes to make this work?
Some infos
The image format is VK_FORMAT_B8G8R8A8_UNORM and I oriented the vulkan setup as found in Sascha Willems examples.
That capability (as most others) have to be queried before usage about whether it is supported. Otherwise it is invalid to use it.
This particular feature is queried by vkGetPhysicalDeviceSurfaceCapabilitiesKHR as pSurfaceCapabilities->supportedCompositeAlpha. It is a bitfield/flag-set, so more than one mode or none can be supported.
I think the result/feature support may be influenced by the VkSurface. That is, how the platform window was created. Or maybe the driver maker simply did not implement it yet (despite that feature being supportable).
Since it worked for you before in OGL, the later is more likely. But couldn't hurt to play with the platform window creation parameters...
Dunno if this is still relevant, but I got it working with transparent windows through GLFW. (If you are not using GLFW you may dismiss this answer!)
As stated here, there are two ways of obtaining window transparency: framebuffer transparency (alpha bit), and window transparency.
For window transparency it is sufficient to call glfwSetWindowOpacicity(GLFWwindow*, float), where the opacity value should be in the range (0, 1].
NOTE: Since GLFW does not support using both transparency methods at the same time, we must still use VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR in the compositeAlpha field of the VkSwapchainCreateInfoKHR object.
Window transparency may not be supported on all systems, which is why GLFW provides us with a function glfwGetWindowOpacity(GLFWwindow*), to check if calling the first methods was successful.
I am using FireBreath to create a cross browser plugin which makes use of some native libraries for the respective platform (some .NET based DLLs for Windows and Objective-C based dylibs/frameworks for Mac). Native libraries display UI screens. In order to improve usability, if the user has a multi/extended monitor setup, i would like the native UIs to appear on the same screen as the browser window is currently on.
If an identifier to the monitor with the browser window can be retrieved, that can be passed down to the native components which can be configured to display their UIs on that monitor. I have used FireBreath's getWindowPosition() method to get the rect coordinates of the plugin and used that info to identify the correct monitor in the Windows platform.
However, the coordinates returned in Mac seems to be always 0 (or 1) irrespective of monitor on which the browser window currently resides. I understand that we have to configure an event model and a drawing model in order for this to work in Mac. I have tried following event/drawing model combinations without much success.
1) Cocoa/CoreGraphics
2) Carbon/CoreGraphics
Any help in this regard is much appreciated. Also please do share if there are other approaches to achieve the same. What i want to achieve is to identify the monitor on which the current active browser window resides in Mac. I am unsure at this point, but it maybe possible to achieve this at Objective-C level (without any changes at FireBreath level). Also please note that i want to support Safari, Firefox and Chrome browsers.
You won't like this answer, but simply put you can't do that on Mac. The problem is that with CoreGraphics you are only given a CGContextRef to work with, and it doesn't know where it will be drawn. It was technically possible in older browsers to get an NSWindow by exploiting some internal implementation details, but many browsers that's no longer possible and it was never supported.
Other drawing models are the same; CoreAnimation you have a CALayer but it doesn't know which screen or monitor it is drawn to. I personally think it's a bit annoying as well, but I do not know of any way to find out which monitor your plugin is rendered to, particularly since most of them actually copy the buffer to something else and render in a different process.
I did manage to come up with a workaround and i am just replying here for the completeness of the thread. As #taxilian explained, it is not possible to retrieve plugin coordinates using the window reference. As an alternative approach, Javascript 'Window' object has 2 properties called 'screenX' and 'screenY' that return X and Y coordinates of the browser window relative to the screen. If the user has an extended monitor setup, these are the absolute coordinates with respect to the full extended screen. We can use these values to determine the monitor with the browser window (if the X coordinate is outside the bounds of the primary monitor's width, then the browser should essentially be on the extended monitor). We can retrieve DOM properties from Firebreath as explained in the following link:
http://www.firebreath.org/display/documentation/Invoking+methods+on+the+DOM
I was able to successfully port, cross compile and run the cairo gears
application in gles backend, on my embedded system target.
http://people.linaro.org/~afrantzis/cairogears-0~git20100719.2b01100+gles2.tar.gz
The ported samples trap, comp, text and shadow run well in cairo1.12.3
and 1.12.4.
But I face problem in running the same in 1.12.14.
I could not run the texture related samples like comp, text, shadow.
Trap plays well but the gradient could not be displayed in the gradient sample.
I use gles backend and converting all image surfaces I load from png
file to gl surface.
Let me know if there is something that should be done for the
texture+gradient samples to work in 1.12.14.
thanks
Sundara raghavan
The problem was because of the need to convert the GL_BGRA,the internal image format of cairo , to GL_RGBA for loading in to GL textures (which were GL_RGBA by default). I solved it by applying an existing patch which uses BGRA GL texture and hence avoids conversion. This was possible because my hardware is capable of both reading as well as creating bgra textures.
The Patch was found here:
http://lists.freedesktop.org/archives/cairo/2013-February/024038.html
I've always been wondering : What librairies/APIs are used by web browser engines (Gecko, WebKit ...) to render images, text, buttons & stuff ?
Think about it, webpages are rendered pixel by pixel identically across operating systems. Yet buttons, drop lists and text look native on most platforms.
The main are
Trident (IE and derivats)
Webkit (Safari, Chrome)
KHTML (KDE Konqueror) This was the base for webkit
Presto (Opera)
You can read more here: http://en.wikipedia.org/wiki/Web_browser_engine
These engines create an object structure of the HTML and then use Components to build the page, the browser engine does not render pixel by pixel but uses buttons, comboboxes, image elements all of which in them self render to a buffer and then those imagebuffers are collapsed to the screen.
Some engines use the plattforms own components (Trident) other use their own with different skins for different plattforms.
For actual rendering I know IE uses windows controlls and Gecko as you noted uses Cairo.
I assume webkit might use gtk or qt but I am not sure and for opera I have no idea but I assume they use some form of framework or toolkit.
I see that Adobe AIR uses WebKit as its render and I see that WebKit (at least the most current build) has some SVG support. Does this mean (and has anyone specifically tried) that an Adobe AIR application could render SVG on an HTML page?
On the offchance that it's helpful (and that you don't already know), Flex can embed SVG at runtime compile time, which effectively converts it to SWF format and embeds it as a resource.
[Embed(source="assets/frog.svg")]
[Bindable]
public var SvgAsset:Class;
More info at Adobe's embedding assets article.
If ActionScript 2: use the com.itechnica.svg (PathToArray) library to load SVGs at SWF runtime and display them (uses XML for SVG parsing):
Using SVG Path Data in Flash, Download button on the right pane.
If ActionScript 3: use the com.zavoo.svg (SvgPath) library to load SVGs at SWF runtime and display them (uses RegExp for SVG parsing):
Source code for SvgLoad and SvgDraw, Download button on the bottom-left.
No, according to the Adobe AIR Developer Center article What's new about HTML, HTML5, CSS, and JavaScript in AIR 2.5?.
SVG
Another feature that has received
a great deal of interest lately is
support for SVG. While present in
WebKit, the current version of Adobe
AIR does not support SVG.
The main reason for not including it
was runtime size concerns (adding it
would have increased the runtime size
by 15 to 20 percent). Initially, the
main pain-points regarding AIR were
the size of the runtime, integration
with the operating system and native
APIs, support for the tag and
new CSS properties, and JavaScript
performance. These priorities, coupled
with a trend toward reduced interest
in SVG graphics, led to SVG support
not being included in the current
version of Adobe AIR.
However, the renewed interest in rich
JavaScript applications powered by
HTML5 canvas and faster JavaScript
engines increased the number of
requests for scriptable vector
graphics via SVG. Thus, adding support
for SVG graphics may be considered for
the next version of AIR.
Adobe AIR can only support SVG once Adobe updates their version of WebKit (AIR's HTML rendering engine) and enables the SVG support within their version of WebKit. Might be a business decision not to (ie Flash).