Qt-interest Archive, January 2007
QPainterPath
Message 1 in thread
Now I'm having trouble with QPainterPath. The follwoign snippet works OK
the first time, but it gets called a second time on a different data
set, and the program just hangs. Here is my code:
QPainterPath path;
path.moveTo(GetXPos(tmpx), GetYPos(tmpy));
do
{
itry++;
if (itry==pDataListy->end())
break;
tmpy=(*itry).GetRealVal();
tmpx=(*itry).GetTimeSec()/60.0f;
path.lineTo(GetXPos(tmpx), GetYPos(tmpy));
}
while (true);
dc->drawPath(path);
I know that when drawPath is called, we are working on a data set
(pDataListy) with about 30K points, and this results in a path that has
about 13876 elements, so it is lots of data. But the previous call to
the same code using different data is about the same size. The second
time, the code hangs in Qt in the file qpaintengine_raster.c, in the
call to QRasterPaintEnginePrivate::rasterize, code that looks like:
while (!done) {
if (antialiased) {
rasterParams.flags |= (QT_FT_RASTER_FLAG_AA |
QT_FT_RASTER_FLAG_DIRECT);
rasterParams.gray_spans = callback;
error = qt_ft_grays_raster.raster_render(*grayRaster,
&rasterParams);
} else {
rasterParams.flags |= QT_FT_RASTER_FLAG_DIRECT;
rasterParams.black_spans = callback;
error = qt_ft_standard_raster.raster_render(*blackRaster,
&rasterParams);
}
// Out of memory, reallocate some more and try again...
if (error == -6) { // -6 is Result_err_OutOfMemory
int new_size = rasterPoolSize * 2;
if (new_size > 1024 * 1024) {
qWarning("QPainter: Rasterization of primitive failed");
return;
}
The code basically loops past the qt_ft_standard_raster.raster_render
call a bunch of time, with error = -6, so it drops to the new_szie until
new_size is When it hangs, the new_szie variable is 524288 -- the next
iteration would result in the qWarning, but it never gets there, it
hangs on the next call to qt_ft_standard_raster.raster_render.
Can anyone point to what the source of the trouble might be? I cant
single-step into qt_ft_standard_raster.reast_render, I get a message
that source is not available.
Again, this is Qt 4.2.1, Visual C++.net 2003, Windows XP.
--
[ signature omitted ]
Message 2 in thread
Kenneth Beck wrote:
> Now I'm having trouble with QPainterPath. The follwoign snippet works
> OK the first time, but it gets called a second time on a different
> data set, and the program just hangs. Here is my code:
>
> QPainterPath path;
> path.moveTo(GetXPos(tmpx), GetYPos(tmpy));
> do
> {
> itry++;
> if (itry==pDataListy->end())
> break;
> tmpy=(*itry).GetRealVal();
> tmpx=(*itry).GetTimeSec()/60.0f;
> path.lineTo(GetXPos(tmpx), GetYPos(tmpy));
> }
> while (true);
> dc->drawPath(path);
>
> I know that when drawPath is called, we are working on a data set
> (pDataListy) with about 30K points, and this results in a path that
> has about 13876 elements, so it is lots of data.
What are you going to do with this path? 13K segments is rather a lot,
if you're going to
draw this to a widget onscreen then you've got more than 10x the level
of resolution that is
going to be drawable. The other question is do you actually need a
QPainterPath, or might
you be better off using drawLines?
- Keith
--
[ signature omitted ]
Message 3 in thread
Thanks for the help, drawLine in QPainter worked OK. I still wonder why
the QPainterPath approach did not work -- there are two instances of the
same widget on a page displaying data stremaing in from a data
acquisition card. It is a lot, at 100 Hz acquistion rate, this chunk i
am debugging with is only about 5 minutes worth. (30K points/100 = 300
sec = 5 min), in Qt3 this application supported over 40 min. That would
be a lot to store in QPainterPath, but the top graph on the page
displayed fine with the same data set (different channel). Not sure why
the bottom graph hung, but it is working now.
Ken
Keith Sabine wrote:
> Kenneth Beck wrote:
>> Now I'm having trouble with QPainterPath. The follwoign snippet works
>> OK the first time, but it gets called a second time on a different
>> data set, and the program just hangs. Here is my code:
>>
>> QPainterPath path;
>> path.moveTo(GetXPos(tmpx), GetYPos(tmpy));
>> do
>> {
>> itry++;
>> if (itry==pDataListy->end())
>> break;
>> tmpy=(*itry).GetRealVal();
>> tmpx=(*itry).GetTimeSec()/60.0f;
>> path.lineTo(GetXPos(tmpx), GetYPos(tmpy));
>> }
>> while (true);
>> dc->drawPath(path);
>>
>> I know that when drawPath is called, we are working on a data set
>> (pDataListy) with about 30K points, and this results in a path that
>> has about 13876 elements, so it is lots of data.
> What are you going to do with this path? 13K segments is rather a lot,
> if you're going to
> draw this to a widget onscreen then you've got more than 10x the level
> of resolution that is
> going to be drawable. The other question is do you actually need a
> QPainterPath, or might
> you be better off using drawLines?
>
> - Keith
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
>
--
[ signature omitted ]
Message 4 in thread
Ken Beck wrote:
> Thanks for the help, drawLine in QPainter worked OK. I still wonder
> why the QPainterPath approach did not work -- there are two instances
> of the same widget on a page displaying data stremaing in from a data
> acquisition card. It is a lot, at 100 Hz acquistion rate, this chunk i
> am debugging with is only about 5 minutes worth. (30K points/100 = 300
> sec = 5 min), in Qt3 this application supported over 40 min. That
> would be a lot to store in QPainterPath, but the top graph on the page
> displayed fine with the same data set (different channel). Not sure
> why the bottom graph hung, but it is working now.
>
I don't know why QPainterPath had a problem, but the approach I would
always take is use the simplest data structure that does the job -
QPainterPath is over complex for drawing just a simple line graph.
And with the data itself, consider sampling it according to the
resolution of your display widget. Say the widget width is 1000 pixels -
pretty much fullscreen on most displays - then if you're displaying 300
seconds worth of data that's about 3 pixels per second's worth. So
rather than try and draw 100 pixels each second, it only makes sense to
draw 3. Of course you'll have to figure out a sampling/smoothing method
for this. You'll find it makes drawing the graph faster as well as
reducing memory usage.
- Keith
--
[ signature omitted ]
Message 5 in thread
Keith Sabine wrote:
> Ken Beck wrote:
>> Thanks for the help, drawLine in QPainter worked OK. I still wonder
>> why the QPainterPath approach did not work -- there are two instances
>> of the same widget on a page displaying data stremaing in from a data
>> acquisition card. It is a lot, at 100 Hz acquistion rate, this chunk i
>> am debugging with is only about 5 minutes worth. (30K points/100 = 300
>> sec = 5 min), in Qt3 this application supported over 40 min. That
>> would be a lot to store in QPainterPath, but the top graph on the page
>> displayed fine with the same data set (different channel). Not sure
>> why the bottom graph hung, but it is working now.
>>
> I don't know why QPainterPath had a problem, but the approach I would
> always take is use the simplest data structure that does the job -
> QPainterPath is over complex for drawing just a simple line graph.
>
> And with the data itself, consider sampling it according to the
> resolution of your display widget. Say the widget width is 1000 pixels -
> pretty much fullscreen on most displays - then if you're displaying 300
> seconds worth of data that's about 3 pixels per second's worth. So
> rather than try and draw 100 pixels each second, it only makes sense to
> draw 3. Of course you'll have to figure out a sampling/smoothing method
> for this. You'll find it makes drawing the graph faster as well as
> reducing memory usage.
>
> - Keith
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
Thanks for the suggestions. Your approach to graphing sounds elegant,
but I may defer to more important issues for now, tackle that later.
Ken
--
[ signature omitted ]
