Announcement

Collapse
No announcement yet.

Qt 5.0 Beta Not Here Due To Difficulties

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by TheBlackCat View Post
    Do you have a source for this? As far as I can tell, QDeclarativeEngine is the interpreter for QML, it is written in C++, but QML is converted into bytecode that the interpreter analyzes and makes use of. In a sense it is similar to how the python interpreter is written in C, but that doesn't mean python code is converted to C code (nor is it always even possible to do so).


    Scenegraph is, you know, a scene graph. The whole point is that you only provide the scene graph, and the interpreter decides how to make use of it at runtime. Using C++ to control how the scene is handled completely defeats the purpose of using a scenegraph in the first place. By definition you need to hand control of the UI over to the scenegraph interpreter or you completely lose the benefit of using a scenegraph in the first place.


    As I keep explaining, QWidget is based on a completely different underlying structure. In QWidget, the widgets handle their own rendering. In scenegraph, all the rendering is handled by the interpreter. You fundamentally cannot render QWidget using a scenegraph without pretty much completely rewriting it from the ground up, at which point it would be just like QML in the end anyway.


    Yes, again, that is because with QWidget the developer writing the widget controls the rendering, and thus can have very fine-grained control of how it operates. But by doing that, you can no longer use scenegraph, because the whole point of scenegraph is that it controls the rendering, not the developer.

    You can't have it both ways. Either you control the rendering, or scenegraph does. You want the benefits of scenegraph, but without the changes in the painting system that make scenegraph possible in the first place.
    1.) Qt beta blog at qt.nokia.com look for the commentary section in the many scenegraph articles since the official devs explain this a bit more based on question
    2.) let me express a bit more precisely here QSceneGraph seem to have 2 uses or components
    a.) is a scene interpreter needed for QML to render in here i agree with you totally named QDeclarativeEngine and here C++ devs have no complains or interest at all
    b.) the rendering engine which is more tied to lighthouse project than QML that provide many nice advances in the render/texture management/shaders/object relation in the framebuffer/canvas operations in hot at the GPU,text|glyph rendering between others <--- this is the part we want to be exposed to the C++ API[seem they wanna to stabilize some more before allow this] and be as flexible as QtPainter/QGLpainter so we can reimplement selected render operation to adapt it to more complex projects and allow at the same time to speed QWidgets render.

    The problem is QML is nice for the mobile space[<-- nokia ...] and graphic simple applications that need cool eye candy but for lets say a multi layered massively tiled rendering[GIS/CAD/etc] or lets say multi input HD video RT processing is deadly slow. i know this is better done in c++ side but you have to rewrite half QT render path to achieve it and many of this changes are already in this engine and using it properly will save you from a truckload of code and hacks, so if they make this changes later in another revision everyone with this kind of workload can make good use of this technology without reinvent the wheel everytime <-- that is all the issue here

    Comment

    Working...
    X