I'm trying to incorporate external Vulkan render commands inside the Qt Quick scenegraph following the example here. I would like to get access to current swap chain image and issue draw commands on it. QVulkanWindow has QVulkanWindow::currentSwapChainImageIndex() and QVulkanWindow::swapChainImage(int index), however I don't know how to get these from a QQuickWindow. QQuickWindow has an associated QSGRendererInterface that can be used as follows:
// m_window is a QQuickWindow*
auto instance = m_window->vulkanInstance();
QSGRendererInterface *rif = m_window->rendererInterface();
auto physicalDevice = *reinterpret_cast<VkPhysicalDevice*>(rif->getResource(m_window, QSGRendererInterface::PhysicalDeviceResource));
Is there a way to query the current swap chain image for a QQuickWindow?
Related
I would like to know if there is a way to inject a predefine layout in Vis.
I managed to save all coordinate of my nodes (X : Y) when i drag an drop each node, which is then saved to the database with a specified ID for each nodes.
What i struggle with is to specified this dataset to vis when i initialize a map with vis ( here is the doc of layout initilisation : http://visjs.org/docs/network/layout.html#)
i would like to put an array with my id nodes and position X Y so that it get saved when user change their layout.
It appears that it is not possible, but maybe there is a hidden way ?
Thanks in advance
This is quite possible:
to set initial layout, just add coordinates to each node (and disable physics so that they don't flow away from their positions):
nodes = [{id:1, label:'some', x:100, y:0 }, ... ];
options = { physics: false, ... };
to get current coordinates, use network.getPositions()
to save those at layout change, you probably want to use the dragEnd event and the on method (use network.getPositions() inside the event handler)
You can opt my implementation in the VisGraphPlugin repo (it's a plugin for TiddlyWiki Classic), just look for dragEnd and saveDataAndOptions, the latter may be of interest.
Instead of saving positions and id's you can simply use getSeed() method to save your layout configuration in a seed. Then, when you start the network again you can load this seed into the layout.randomSeed to have the same configuration.
The documentation for getSeed() says:
If you like the layout of your network and would like it to start in the same way next time, ask for the seed using this method and put it in the layout.randomSeed option.
I have a QQuickItem fetched from C++ side like this.
QQuickItem * my_item = qmlEngine->rootObjects()[0]->findChild<QQuickItem*>("ItemObjectName");
my_item is valid & has all the properties set on to it.
Scenario
I have 2 windows which need this QQuickItem to be drawn on alterantively. I want to render this my_item to a different window. This works perfectly fine as long as I set the Parent of the my_item to the other window
// the_other_window is a QQuickWindow
QQuickWindow * the_other_window;
// here I set parent
my_item->setParentItem(the_other_window->contentItem());
This requires me to do setParentItem again back to my_item's original window otherwise it goes invisible on the original window. This is working but gives me unnecessary dependency. Instead I am trying to create a copy of the QQuickItem & do a setParentItem on that. By copying like this:
QQuickItem * item_copy = new QQuickItem(my_item);
Problem:
But this doesn't seem to create a copy of the QQuickItem & hence I don't see a copy of my_item on the_other_window.
Question:
All I want to know is, how can I create a valid copy a QQuickItem into another pointer say QQuickItem * item_copy & render it on a different window without affecting the visibility/state of the original QQuickItem?
The interface of QQuickItem doesn't provide clonability. If it did, then all its subclasses would have to reimplement a virtual clone() function.
Indeed, the QQuickItem derives from QObject which explicitly disables copy-like operations (copy constructor and assignment operator), so they're disabled in any QQuickItem-derived class as well. Even if you have a specific subclass of QQuickItem, which you think you know how to copy, you can't implement "real" copying for it.
The closest thing to do in the latter case is to instantiate a new, blank item of your type and manually copy all values of relevant properties from the old to the new instance. You can encapsulate code that in a copy function.
I've decided no to use OpenCV. I will use the QCamera class. Everything is working perfect to this moment. I can capture and save images wherever I want, but the problem is how I can set the camera to a label or graphics view?
I mean, to see what is happening at the moment. When I make infinite loop everything crashes. Write any information you know, cause there are no examples how to do that, or I just can't see. If you can please write some source code.
Use QCameraVievFinder or QVideoWidget widgets ( docs - here) for that purpose, here is example for you:
#include <QCameraViewfinder>
// .......
QCamera *camera=new QCamera(this);
QCameraViewfinder *viewfinder = new QCameraViewfinder(this);
viewfinder->setSizePolicy(QSizePolicy::Maximum,QSizePolicy::Maximum);
camera->setViewfinder(viewfinder);
setCentralWidget(viewfinder);
//viewfinder->show();
camera->start(); // to start the viewfinder
Note: you need to add to your *,pro file this config to use them: QT += multimedia multimediawidgets
If you want a bit more low level widget (to process every frame the way you like (face detection etc), subclass QAbstractVideoSurface, docs - here
or try to connect to QVideoProbe class (docs - here), though i could not do it myself, this class is a bit experimental i guess, didn't worked
The documentation for QWidget::winId states (among other things) "If a widget is non-native (alien) and winId is invoked on it, that widget will be provided a native handle."
I'm not sure what 'alien' means in that context, but I'm choosing to ignore it for now. :)
So assuming that my widget now has a valid native handle associated with it, can I then pass that native handle to another process and into QWidget::find and get a valid QWidget object back within that second process?
I probably don't need to do too much else to the widget in the second process other than show/hide it and attach it to a parent widget. (It is guaranteed to not be attached to any parent widgets in the first process and never visible in the context of the first process).
If all the above works:
How much control will the second process have over that widget?
Will the first process receive user input events as if it were attached
to the first process's UI, and will the first process be able to update the widget as normal?
James
Let's take a look at Qt sources.
QWidget *QWidget::find(WId id)
{
return QWidgetPrivate::mapper ? QWidgetPrivate::mapper->value(id, 0) : 0;
}
find() can find a widget only if mapper contains it. The mapper is a static QHash<WId, QWidget *> variable. Items are inserted in this hash only in the QWidgetPrivate::setWinId method.
So, if a widget with a WId was created in another process, you can't find it using QWidget::find. This function doesn't use any native OS functions to find widgets.
Also see general description of alien widgets in Qt documentation:
Introduced in Qt 4.4, alien widgets are widgets unknown to the
windowing system. They do not have a native window handle associated
with them. This feature significantly speeds up widget painting,
resizing, and removes flicker.
In my Qt widget I sometimes get this error:
malloc(): smallbin double linked list corrupted
It does not happen all the time but I think I have narrowed it down to when it starts.
I have a QGraphicsView and QGraphicsScene and there I'm drawing lines whos points are stored in a vector. Reason for this is I need to pass this points to another library. Once I draw the points I have an option if I click on a line I'm prompted to another window where I can change the coordinates of a line.
ResizeDialog *dialog = new ResizeDialog(this);
dialog->exec();
delete dialog;
The above code is the code I use to open a new QDialog. I know if I use this->close() the
qt malloc(): smallbin double linked list corrupted does not appear but then I lose the instance of QGraphicsView. Reason I need to keep the QGraphicsView window open if I need to chose to add further lines.
Any advice on how I can eliminate this issue wold be helpful.
Rather than using delete dialog;, use dialog->deleteLater();. I assume the small code portion is inside a slot of the object referenced by "this", and direct deletion is source of trouble as ResizeDialog *dialog = new ResizeDialog(this); affect the parent object this.