Page 1 of 5

Awesomium - Chromium based Framework

Posted: Sun Nov 20, 2011 8:39 pm
by PMV
Awesomium is based on chromium, the free open source project from
Google, base of the browser Google Chrome. Render engine is WebKit.
http://www.awesomium.com

Awesomium is a library that writes the rendered image into a pixel-buffer.
This pixel-buffer can be easily copied into everything like file, image,
gadget, window, sprite, or texture. And this is what my include already
can. The Awesomium SDK can be installed on Windows, Mac and Linux.
But the include is just tested with the windows version and needs to be
reworked for Mac OS and Linux. Additional it is still beta and not documented.
Please feel free to check out Awesomium yourself. :wink:

Everything needed is now in this ZIP-file:
http://dl.dropbox.com/u/5498515/Awesomium_Include.zip
Please not, that you can still download and install the
Awesomium SDK at your own. It is still only tested on windows
and contains only needed files for windows.

update: (26.06.2012)
+ fixed: for ResourceRequestCallback(ID.i, *AweRequest.Awesomium_Request), now *AweRequest\Url returns full URL
+ fixed: Display issue for special width/ height values when using Awesomium-Gadget
+ fixed: Alpha-channel was lost for sprites because of DX9-bug. Now, as a workaround, when using mode #PB_Sprite_AlphaBlending, the whole sprite is repainted always!
+ added: Awesomium_JS_Execute(), Awesomium_JS_Execute_Return_XXX()
+ added: parameter "ChildProcessPath" for InitAwesomium() and an OSVersion()-check for windows, feature deactivated for linux because of missing code
+ added: parameter "PowerOf2" for CreateAwesomiumTexture() to always get a 2^X width and hight for texture. Attention: Will result in free space, right and bottom of texture, when width/ height is not 2^X! You will need to scale the texture with a material-script. There is currently no function in PB to scale the texture at runtime.
+ updated: Awesomium to version 1.6.6
+ updated: include works with PB4.61, too.

update: (17.02.2012)
+ fixed: message of missing avutil-50.dll
+ fixed: some small bugs
+ update: Browser example displays now state of request
+ update: Browser example have buttons for back and forward
+ update: every function needs now a Awesomium-ID instead of GadgetNr or WindowNr
+ update: now all public functions have the prefix "Awesomium_" except to create new objects
-> this are OpenAwesomiumWindow(), CreateAwesomiumTexture(), AwesomiumGadget(), CreateAwesomiumSprite(), CreateAwesomiumSprite3D()
+ update: now all internal functions have the prefix "Awe_"
+ update: now an awesomium-window can display tooltips
+ new: example with awesomium as a borderless window
+ new: CreateAwesomiumTexture() + example with Mouseinput (thanks Comtois)
+ new: CreateAwesomiumSprite/3D() + example
+ new: Awesomium_ResourceRequestCallback()
-> get formdata and identifies "multipart/form-data" to get selected filepath, too!
+ new: Awesomium_JS_innerHTML(), Awesomium_JS_InnerText()
+ new: Awesomium_InjectMousePos(), Awesomium_InjectMouseButton/DX()
+ new: everything packed into a zip-file with SDK 1.6.4 for windows and jQuery 1.7.1

update: (20.12.2011)
can't stop on this one and still many tests to do :wink:
+ fixed: var-types for function definition
+ updated: optimized redraw function again
+ updated: prepared for new output-buffers like borderless window, texture or sprite
+ updated: events for gadget-output now cross-platform
+ new: callback-function-wrapper to nativ PB
+ new: favicon callback (uses JS inside of Awesomium and PB-HTTP-Lib)
+ new: browser example
+ new: (Windows only) example for borderless window with alpha-support, do you know a website with transparent background?

update: (04.12.2011)
now it is the result of one weekend and one night :lol:
+ optional config on initialization (UserAgent, disable JS, CustomCSS, ...)
+ title callback
+ keyboard events (windows only)
+ buffer update optimized
+ childprocess named like mainprocess
+ filerequester

(Image from Browser Example)
Image

(image from Engine3D Example)
Image


original post from 20.11.2011:
I can't hold myself, so i began this include ... just a first step but
it shows what is possible with Awesomium. And i'm really impressed.
:shock: ... you can do almost everything. I just can't get the
keyboard injection to work with it. :cry:

It wouldn't be bad if some one could help here, because i could
provide this functionality in the include, too :) I have just
tested it with PB v4.60 x86 in Unicode on Widnows ... but it should
be working with ASII and on Linux and Mac OSX with the right
SDK (and little changes?), too.

Heavy development with this browser engine is planned not before
Christmas for me, so don't be afraid when the next update will
not come before next year. :lol: Especially i don't know if
i really need so much functionality. :mrgreen: ... this is just the
result of one weekend. :wink:

Re: Awesomium - Chromium based Framework

Posted: Sun Nov 20, 2011 9:38 pm
by idle
looks interesting, I tried modifying it for Linux but it's didn't display anything

Re: Awesomium - Chromium based Framework

Posted: Mon Nov 21, 2011 12:03 am
by luis
PMV wrote:I can't hold myself, so i began this include ... just a first step but
it shows what is possible with Awesomium.
I don't have time to try your code right now but I just wanted to thank you for sharing it :)

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 5:48 pm
by fsw
Good job 8)

Do I need to install Chrome or Chromium in order to get flash activated :?:

Thanks
:mrgreen:

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 6:19 pm
by USCode
Looks neat but I'm not quite clear what additional functionality this gives us that the WebGadget doesn't already?
Is it because Awesomium is Chromium/WebKit based, which is viewed as superior to IE and others?

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 6:31 pm
by wilbert
It's Chromium / Webkit based but as far as I understand it can render to a pixel buffer making it very flexible.

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 6:41 pm
by Kuron
USCode wrote:Looks neat but I'm not quite clear what additional functionality this gives us that the WebGadget doesn't already?
Is it because Awesomium is Chromium/WebKit based, which is viewed as superior to IE and others?
IE has never been standards compliant and is even worse with emerging technologies. HTML 5 is extremely popular. Opera is the best at supporting it and WebKit is the second best at supporting it. IE is the worst at supporting it. Since you can't access Opera's rendering engine, WebKit is the best choice if you are wanting to write an application that includes a HTML 5 capable browser.

Comparison of layout engines (HTML5)

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 8:13 pm
by Seymour Clufley
USCode wrote:Chromium/WebKit based, which is viewed as superior to IE and others?
"Viewed as" superior? There's no question about it. IE has been an abysmal browser for years, antiquated and slow.

Having said that, it is getting better. IE8 was a pathetic 23% capable, IE9 was 52%, and IE10 is 80%. MS have got the message.

Browser capability comparison

Re: Awesomium - Chromium based Framework

Posted: Wed Nov 23, 2011 10:06 pm
by PMV
fsw wrote:Good job 8)

Do I need to install Chrome or Chromium in order to get flash activated :?:

Thanks
:mrgreen:
Flash needs to be activated separate through the plugin-system of this, but i
doesn't have looked what is needed for that. Could be just to be one value
set to "true" :lol: ... it needs to be set at initialization in awe_webcore_initialize(),
the awe_webcore_initialize_default() doesn't activate this, but thats what i'm
using in my tests.
USCode wrote:Looks neat but I'm not quite clear what additional functionality this gives us that the WebGadget doesn't already?
Is it because Awesomium is Chromium/WebKit based, which is viewed as superior to IE and others?
nothing special :mrgreen:
You can render to everything what you want: ImageOutput,
TextureOutput, WindowOutput, CanvasOutput as easy as possible
or to everything else because you can directly read from the
buffer. Also you can call one function to get an Image (JPG, PNG)
You can send javascript at runtime to the engine that is exceuted directly
Getting Post values, http headers, ...
set user-agent and other http headers
deactivate Javascript
Proxy
cross-platform (SDK available for Mac, Linux and Windows)
same engine as Chrome, that means
-> really optimized engine
-> if the process crashes, it will not crash the whole program (and you can get the information, if it crashes to handle that)
-> latest web page technology support up to css3 and html5
-> page will look all the same, because you will provide the DLLs with your program that render it
-> no need to hope they have installed the latest IE :lol:

and there is much more, many stuff that most of use will not need
:wink:

It is just a little overhead to implement all that stuff.
You see if it all is working ... it is no comparison to the webgadget.
But if you think you don't need it, you really doesn't need this. :)

For example, i want to create a CSS3 based Game Menu where i need to get
every refresh of a link, upload and download data in the future, jumping from
lokal files to a web page and back without notice from the user, i will look
if i can make that page even borderless with alphablend (on vista and 7)
as Awesomium provides the needed information, too :shock:
and i can use JS-Objects (my JSON include :mrgreen: ) ... to send data
to a html-template to fill it with content with less code as possible
... at the end, the player will not think at the first place, that it is a (web)page


MFG PMV

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 4:42 pm
by PMV
this post has been created within the example

update: (04.12.2011)
now it is the result of one weekend and one night :lol:
+ optional config on initialization (UserAgent, disable JS, CustomCSS, ...)
+ title callback
+ keyboard events (windows only)
+ buffer update optimized
+ childprocess named like mainprocess
+ filerequester

For windows, there is a special function on Awesomium to paste the
window-message. If some one wants to get this run on linux or mac,
please take a look at this info:
http://support.awesomium.com/kb/general ... oard-input
... to get the childprozess-name feature on linux or mac, i have left
out the CompilerElse part for that. It needs to be written, too. :)

One question: What is the right type for the bool-parameters?
I have used long ... but i don't think that it is the right one. :cry:


MFG PMV

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 5:20 pm
by Shield
PMV wrote: One question: What is the right type for the bool-parameters?
I have used long ... but i don't think that it is the right one. :cry:
That depends on the compiler the library has been created with.
I assume it's created with VS (hence all the VS examples), so the bool data type
uses one byte.

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 5:51 pm
by Danilo
bool = size: 1 byte
BOOL = size: 4 byte

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 7:12 pm
by PMV
thanks ... but how can it be, that this two lines

Code: Select all

; _OSMExport bool awe_is_child_process(HINSTANCE hInstance);
PrototypeC.b awe_is_child_process(hInstance.i)
;[...]
Debug RSet(Bin(awe_is_child_process(GetModuleHandle_(0))), 32, "0")
Debug awe_is_child_process(GetModuleHandle_(0))
are returning this in debugger:
00000000000110001111111000000000
1637888

Is PB ignoring the return type? Shouldn't this be raise an error
or something, when the return type of this Prototype is set to
byte?

MFG PMV

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 7:22 pm
by Danilo
Try the flag #PB_Byte for Bin() and
b.b = awe_is_child_process(GetModuleHandle_(0))
Debug b
Debug awe_is_child_process(GetModuleHandle_(0)) & $FF

You already know PB does not check much.

Re: Awesomium - Chromium based Framework

Posted: Sun Dec 04, 2011 7:30 pm
by Polo
Don't know much about Chromium but it'd be nice to use it with a .lib .a on the 3 platforms instead of a DLL/Dylib etc.
That'd make a very good replacement to the webgadget, especially on windows where it uses IE...