Skip to content

Conversation

patrickelectric
Copy link
Member

@patrickelectric patrickelectric commented Dec 16, 2019

@patrickelectric patrickelectric changed the title waterfallplot: Use OpenGL WIP: waterfallplot: Use OpenGL Dec 16, 2019
@patrickelectric patrickelectric changed the title WIP: waterfallplot: Use OpenGL waterfallplot: Use OpenGL Dec 16, 2019
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
@jaxxzer
Copy link
Member

jaxxzer commented Dec 17, 2019

@patrickelectric are you still encountering the aberrations on the left edge of the plot?

@patrickelectric
Copy link
Member Author

@jaxxzer did you take a look in the video ? You can see it in the left corner.
My idea is to merge this and fix this issue, right now this patch reduce the cpu usage dramatically

@jaxxzer
Copy link
Member

jaxxzer commented Dec 17, 2019

Yes I saw the problems that you mentioned in the past in the video, I thought it might have been fixed but an old video.

My idea is to merge this and fix this issue, right now this patch reduce the cpu usage dramatically

I'm hesitant to approve it in that case. I would prefer no graphical errors vs cpu usage (must have vs nice to have IMO). You know better than I what it will take to correct the problems after merge. I'll leave this to your judgement as maintainer.

@patrickelectric
Copy link
Member Author

@jaxxzer this PR is a intermediate step to make both waterfallplot and polarplot full OpenGL and remove the QML elements (like the shadereffect). Moving waterfallplot to this final version will require a bigger code change for both waterfallplot and polarplot making this patch much worst to review.
If you agree please merge, otherwise it'll not be a simple patch as it's already.

The final PR is already in progress based in this changes and the last version of polarplot.

_painter->drawPixmap(_painter->viewport(), pix, QRect(0, 0, _image.width(), _image.height()));

emit drawHorizontalRatioChanged();
emit drawVerticalRatioChanged();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you think about merging those two emits into one? if the horizontal and vertical changes at the same time probably there will be one less redraw

}
_currentDrawIndex++; // This can get to be an issue at very fast update rates from ping

for (int i = virtualHeight; i < _image.height(); i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how fast is this but perhaps this is something that could be improved by QConcurrent?

*
* @return double
*/
Q_INVOKABLE double drawHorizontalRatio() { return static_cast<double>(_currentDrawIndex + 1) / _image.width(); }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const.

*
* @return double
*/
Q_INVOKABLE double drawVerticalRatio()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants