I'm writing a app that uses Vulkan/OpenGL for rendering, GLFW for windowing. This does by default does not support precision gestures that modern windows (>8 I guess) supports (as GLFW does not have support for it).
Going trough the Win32 API docs, it seems that to add precision gesture manipulation to win32 apps, one needs to use the Direct Manipulation API. Does this require using a DirectX rendering backend? I've gone through the example app provided here, but that uses by default DirectX. I could copy over the framebuffers and whatnot, but was wondering if using DirectX is a requirement.
Related
Every tutorial on OpenGL in Win32 I read instructs to use the wgl functions, wglCreateContext() and wglMakeCurrent().
Is this the only way of doing OpenGL in a Windows environment?
Are these functions part of the OpenGL API or the Window API?
Is this the only way of doing OpenGL in a Windows environment?
Yes, aside from getting a library like GLFW to do it for you (and take care of the cross-platform issues).
Are these functions part of the OpenGL API or the Window API?
The Windows API.
OpenGL specifies some semantics of OpenGL contexts (that they can be created, made current to the thread, and are required for any OpenGL commands to work), but does not specify an API for them, so it is system dependent. Windows has wglCreateContext, and Linux has glXCreateContext
Like with toolkits such as qT, wxwidgets and such, how does an API designer provide and api that is the same, even though it calls totally different system calls to do so? For example, in Windows OS you have to mess around with a whole lot of functions in the GDI. On Linux you have to mess around with a whole lot of functions in XLib and whatever other layers the distribution has on top of in. So how how can you design an widgit kit that can unify all that functionality? so that say CreateWindow() will create a windon on any platform? I don't comprehend how this can be done.
Instead of using Xlib or GDI, you could use something that is more universal. For example, you could use OpenGL, which is supported everywhere. I think that is what Blender's UI does.
Some toolkits can be modified to use some kind of backend for each platform they support. This is basically what Qt does. On Mac OS X, Qt apps use Cocoa as a backend. Qt for OS X was made specifically for that OS. However, there are other Qt implementations on other platforms, so that's what makes Qt work on more than one platform. SWT for Java works the same way (using the OS's native toolkit as a backend).
Other toolkits can use some kind of high-level layer to render. For example, Swing for Java is rendered purely using Java APIs, and is not tied to any platform at all.
I would like to ask the SO community for the following information:
- Is it possible to compile WebKit for Windows8-Metro Environment, either in the form of a WinRT component or just as a linked library in a C++/XAML application?
- Which are the main steps to achieve this goal?
- Which are the possible things that would make this not possible or very difficult?
- Is it an endeavour someone is working on just now?
- Is it possible to gather interested people so they work on this?
I think you will not be able to just "compile" Webkit for WinRT/Metro Style. Metro Style applications are restricted in the kind of API calls they can make, for example there is no GDI/GDI+/MFC for WinRT. WebKit has several building modes that you can use, you can either build it using QT as rendering engine, or using GTK, or plain GDI, but on all those cases, when you create new builds for Windows OSes you will be using GDI at the very end.
Nevertheless, you could modify Webkit source code and add a new rendering engine that uses WinRT new APIs. You could probably become famous if you do.
As a side note, even when there is a "Windows Store" version of Chrome, by looking at the source code of Chromium it seems to me that this version is just a simple app launcher that communicates with the "normal" desktop version using an IPC channel. It does not appear to be a real Windows Store build of the whole source code.
I am not sure if the WinRT environment will allow this, but there is a project called Awesomium that is a wrapper around Google Chrome and Google Chrome is based on WebKit I think. It also has a .NET wrapper, so you can embedd it onto your .NET app.
I never tried using it, neither I know about if this library is applicable with WinRT, but at least it is a start.
Awesomium
Awesomium .NET samples
DownMakerWPF, an application embedding it to display markdown.
WinRT is a combination of managed and native code, so, you have a chance to port WebKit, but remember - native code have some sandbox restrictions.
Also you can choose XNA instead.
HP webOS needs javascript,HTML to develop applications.but is it possible whatever we can do through javascript in c++ or c? have they given any API list for it?I found PDK is for openGL game porting .Have they given any option for C++ developers?
If using C/C++, you are essentially on-your-own when it comes to the interface unless you build a plugin in for a hybrid PDK app that uses HTML and JavaScript for the UI. You are provided with APIs for system services and accessing the hardware (drawing to the screen, keyboard presses, etc.) in C++. The intention is that you'll use C/C++ when you need speed, and JavaScript the rest of the time when speed is less critical (as in, you're not doing anything that the user will notice as slower than if you had written the code in C/C++).
To answer the question I sense lies beneath your question, you're probably going to have to learn JavaScript to program for webOS unless you want to develop openGL games only.
We currently have a shared DirectX code base that renders our UI and is used in our PC side application and via an ActiveX in web pages.
I have written some WebGL demos and they perform great, no plugin mess and get rid of ancient ActiveX!
This obviously raises the problem of having a split code base for the PC application and the Web UI.
As WebGL is based on the OpenGL ES 2.0 specification would it be possible to have a standard code base and write a interpreter so that either:
-The WebGL code can be modified to compile as OpenGL
-OpenGL can be modified to work in a web page
The khronos specifications are new to me, so this is sort of speculative as I am peforming research at the moment.
Does anyone with more knowledge of 3D graphics and a better understanding of the coding syntax help me out?
One way is to have a PC app to enclose a WebGL-capable browser inside (together with a simple http server) to run the same rendering technique as the web App.
This will reduce the maintenance and development costs for both platforms.