So as nobody answered this question, I found a workaround which seems to resolve my issue. I changed the stroke width from 1 to 1.5. However this unfortunately doesn't explain what happened here, and why the ShapePath object behaves this way. I have my own idea about that: I think it's a kind of pen alignment, as in GDI+ (https://docs.microsoft.com/en-us/windows/win32/api/gdiplusenums/ne-gdiplusenums-penalignment), however I found absolutely no way to configure that.

So below is my solution, which works correctly in all situations on my side:

import QtQuick 2.15 import QtQuick.Window 2.15 import QtQuick.Controls 2.15 import QtQuick.Shapes 1.15 import QtGraphicalEffects 1.15 import QtQuick.Templates 2.15 as T /** * Dashed border *@author JMR */ T.Control { // advanced properties property real m_StrokeWidth: 1.5 property int m_Radius: 5 property string m_FillColor: "transparent" property string m_StrokeColor: "#bac1db" /** * Background rectangle */ Rectangle { // common properties anchors.fill: parent color: m_FillColor radius: m_Radius /** * Dashed outline shape */ Shape { // common properties id: shDashedBorder anchors.fill: parent anchors.margins: 0 //layer.enabled: true //layer.samples: 8 smooth: true clip: true /** * Dashed outline shape path */ ShapePath { // common properties fillColor: "transparent" strokeColor: m_StrokeColor strokeWidth: m_StrokeWidth strokeStyle: ShapePath.DashLine dashPattern: [5, 5] startX: m_Radius startY: 0 // path commands PathLine {x: shDashedBorder.width - m_Radius; y: 0;} PathQuad {x: shDashedBorder.width; y: m_Radius; controlX: shDashedBorder.width; controlY: 0;} PathLine {x: shDashedBorder.width; y: shDashedBorder.height - m_Radius;} PathQuad {x: shDashedBorder.width - m_Radius; y: shDashedBorder.height; controlX: shDashedBorder.width; controlY: shDashedBorder.height;} PathLine {x: m_Radius; y: shDashedBorder.height;} PathQuad {x: 0; y: shDashedBorder.height - m_Radius; controlX: 0; controlY: shDashedBorder.height;} PathLine {x: 0; y: m_Radius;} PathQuad {x: m_Radius; y: 0; controlX: 0; controlY: 0;} } } } }

Use longer names that are descriptive:
this_pointer_to_object

I would avoid leading underscore outside of any QML use cases. I think QML uses them in places that are considered private. Not 100% sure on that. I would also not use leading underscore in C++ at all. C++ specifically reserves them for special cases.

In my QML naming I do this:

ListView { id: scanned_items_listview delegate: Item { id: scanned_items_listview_delegate } }

Now for variables in javascript it is somewhat less critical because the names only exist in the script itself (except outside resources). In that case I would avoid any and all reserved symbols that javascript uses (even for the latest version of JS). That way if the v8 engine gets updated to a newer JS version then you won't conflict with those newer symbols. For JS names being more descriptive is far less likely for naming collisions. I also avoid simple words like "object". If I need a quick object var I just do: var obj. But if I need to differentiate I will do nobj (new object). Again, this is because the scope of the variables in the JS is much smaller than the scope of a QML Item for instance.

@T_Eng Also to say that my GUI is Qt Quick Qml code and I am trying to fill a TextField qml type

http://www.qtcentre.org/threads/66403-How-to-get-Object-s-pointer-instantiated-in-QML-engine?p=291959#post291959

Hi, welcome to devnet.

A better and more portable design would be if an engine did not run its own loop. The most popular way to do that is to provide a kind of Initialize(), Frame() and Shutdown() interface that you could call from a loop provided by whatever windowing framework (most of them usually have that). The Frame() part would measure the time elapsed from last frame and advance the states proportionally to that.
If you don't want to go that path (just make sure you really don't) you could also run the two loops in parallel, starting your engine's loop in a worker thread. This leads to some synchronization issues, but with some work could be manageable.

Again - it's better if the engine does not provide it's own OpenGL bindings but uses the ones provided by the windowing framework (e.g. QOpenGLFunctions in case of Qt). There should be no problem in using GLEW along with Qt, just make sure you do your GLEW/OpenGL calls with a current GL context provided by Qt.

QGLWidget is replaced now with a more modern QOpenGLWidget. If all you need is a window and input management (like with GLFW) then consider using QWindow with an OpenGL surface format instead. You will get better performance and drop the requirement of QtWidgets module.
As for triggering the update - there's an update() method for that. You can call it how often you need and it will schedule OpenGL painting. The usual way to tackle this is either using a timer or calling update() at the end of the painting method to schedule updates "as often as possible" i.e. as often as v-sync allows.

@dante I doubt that it will work readily with QML. Javascript support in QML is very restricted as compared to that of Web-Browsers. It lacks of certain objects which are mostly used in these web-browsers supported Javascripts.
You can find more info here:
http://doc.qt.io/qt-5/qtqml-javascript-hostenvironment.html
http://doc.qt.io/qt-5/qtqml-javascript-expressions.html
http://doc.qt.io/qt-5/qtqml-javascript-hostenvironment.html#javascript-environment-restrictions
You will need to create you own port of it without those restrictions.
For eg. here is a blog post for porting-three-js-code-to-canvas3d. Something similar will be needed for the rest too.