My approach so far is a choice based on lod, from low to high:
- draw nothing
I would despise a system where repeated zoom-outs
eventually resulted in "draw nothing". If you draw
nothing then I am lead to believe that there is
nothing there.
- draw the bounding rect
- draw the rectangles d
On 7 December 2016 at 21:13, Michael Sué wrote:
> Hi,
>
>>I used some naive approach, based on QPainter world transform, and the width,
>>height and area of the bounding box.
>
> You probably know that there is system support for this with the function
> "QStyleOptionGraphicsItem::levelOfDetailF
On 6 December 2016 at 15:53, Ch'Gans wrote:
> Something else I had in mind, is to use QPainterPath::simplified()
> and/or QPainterPath::toFillPolygons() to paint a "far" item and use
> the "real" painter path to paint a "close" item. Basically as you zoom
> in, there are less items to draw, so you
I'm pretty sure QPainterPath is reentrant especially since QPainter depends
on QPainterPath and QPainter is reentrant.
On Tue, Dec 6, 2016 at 5:56 PM Ch'Gans wrote:
> On 7 December 2016 at 01:18, Philip Schuchardt wrote:
> > Since QGraphicsView can only render in the main gui thread, rendering
On 7 December 2016 at 01:18, Philip Schuchardt wrote:
> Since QGraphicsView can only render in the main gui thread, rendering in a
> separate process will prevent the blocking on the main thread. You could
> even implement "big pixel" zooming. You zoom in on the visible buffer while
> a back buffe
On 6 December 2016 at 22:26, Ulf Hermann wrote:
> Hello,
>
> I had a somewhat similar, but not quite the same problem when building the
> timeline view for the QML profiler in Qt Creator. It's currently usable with
> up to about 1 million events in the timeline and you can zoom and scroll it.
> Th
Since QGraphicsView can only render in the main gui thread, rendering in a
separate process will prevent the blocking on the main thread. You could
even implement "big pixel" zooming. You zoom in on the visible buffer while
a back buffer is being rendered in the background by the separate process.
Hello,
I had a somewhat similar, but not quite the same problem when building the
timeline view for the QML profiler in Qt Creator. It's currently usable with up
to about 1 million events in the timeline and you can zoom and scroll it. There
might be potential for further optimization. I used
On 6 December 2016 at 13:27, Philip Schuchardt wrote:
> I've always wondered if you could put a QGraphicsScene in another process
> and then render to shared memory buffer QSharedMemory
> (https://doc.qt.io/qt-5/qtcore-ipc-sharedmemory-example.html). Then you
> could query the shared memory (as a
I've always wondered if you could put a QGraphicsScene in another process
and then render to shared memory buffer QSharedMemory (
https://doc.qt.io/qt-5/qtcore-ipc-sharedmemory-example.html). Then you
could query the shared memory (as a pixmap) in the main application. This
would get around the QGr
On 8 September 2016 at 18:29, Tomasz Siekierda wrote:
> On 8 September 2016 at 04:17, Ch'Gans wrote:
>>
>> Hi there,
>>
>> I'm currently working on a Gerber viewer (Gerber is an old file format
>> still widely used in the electronics PCB manufacturing industry,
>> dating as far back as the old ph
On 8 September 2016 at 04:17, Ch'Gans wrote:
> Hi there,
>
> I'm currently working on a Gerber viewer (Gerber is an old file format
> still widely used in the electronics PCB manufacturing industry,
> dating as far back as the old photo-plotter methods), some of these
> files can get pretty big a
Hi there,
I'm currently working on a Gerber viewer (Gerber is an old file format
still widely used in the electronics PCB manufacturing industry,
dating as far back as the old photo-plotter methods), some of these
files can get pretty big and I end up with a scene that contains up to
2 millions QG
13 matches
Mail list logo
