TimVanMourik
Rendering problem for nodes on the rest of the view
There is some rendering problem (on all platforms) with Nodes (QGraphicsPathItem) being rendered on the rest of the view. Not sure why. This bug is rather persistent and despite extensive searches on Google and StackOverflow, I have not been able to find a solution, or anyone with the same problem.
The problem presents itself when you’ve got more than +-6 nodes in the editor. The rendering issues are traces from nodes that are moved around where the rest of the interface isn’t updated.
The stack of QObjects/QWidgets is as follows:
- MainWindow, inherits QMainWindow
-QSplitter
- QSplitter
- QSplitter
- QTabWidget
- QStackedWidget
-MyEditor, inherits QGraphicsView
- QGraphicsScene
- QStackedWidget
-MyEditor, inherits QGraphicsView
- QTabWidget
- QSplitter
- QSplitter
Any clue or fix would be appreciated. The solution may just be a single setting in the QGraphicsScene that I don't know about, or a bug in the Qt code, or anything in between.
This issue now has a funding of 0.09 ETH (52.2 USD) attached to it.
- If you would like to work on this issue you can claim it here.
- If you've completed this issue and want to claim the bounty you can do so here
Hi, I have jumped in by accident and run as was curious what this thing is :-)
docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix porcupine works fine for me on Ubuntu 16.04 LTS.
Do you have any reproducible scenario for this issue (pork file)?
Good point, I’ll add one tomorrow. And I’ll edit the description that it starts showing up from +-6 nodes onwards and that it’s a trace from nodes are being moved around.
Once again, bug in QT code. the code that @cryptomental proposed is a good fix if you're using openGL processing only. It will break in other situations. Throwing the program into a stack overflow revealed that QGraphicsScene is getting stuck due to the time that QT is freezing the process for download. Once again, a QT issue, To fix on your end before they update I would use a different charting call, or perhaps a different graphics drawing call. I can submit a fix if warranted.
Please let me know how you;'d like to proceed!
Hi @jgr33nwood , ah, more Qt bugs. Is this one related to the bug in #20, and could you please link to the respective bug? Not sure what solution by @cryptomental you're referring to, as I don't think he mentioned any code. I'm not quite sure what you mean by 'that QT is freezing the process for download', but as it's related to an internal bug, it might not matter too much.
No idea in what time frame Qt is going to fix this problem, but I'm not inclined to wait for it. So yes, I'd be happy to consider solutions with different drawing mechanisms! Any specific direction mind?
Spent a little time looking at this bug last night. I was able to recreate it with only two nodes, and what I found that was interesting is that it never happens with the first node added (either manually or loaded from a .pork), but will happen with every node after. What seemed to start the overlap was when the parameter widget or code editor changed (either resized or code was generated). Made me think that all the non-central widgets just needed to be repainted after a change, but I wasn't able to get it working with the time I had. If you don't have a fix by tonight I'll revisit it, and see if I can get something working.
@tiro6090 That’s a very interesting observation that I hadn’t realised yet! I do not have a fix yet so if you’re able to solve it, the bounty is yours! Let me know of there’s anything I can help you with.
@jgr33nwood let me know if you are still planning on handling this. if not, i need to reject your claim so someone else can take it. @TimVanMourik let me know what you want to do here
I believe I already rejcted the claim, so it’s up for grabs! Did you have any luck with your investigation, @tiro6090 ?
Didn't have too much luck with my investigation. Repainting or relaying out the widgets didn't seem to help. I wouldn't mind giving it one last stab though since I'll have some time either today or tomorrow to get back into it. @TimVanMourik were you able to verify that this is a bug with qt? I didn't see anything that verified that, but I don't want to fix it with a workaround if it's actually a bug in the Porcupine code and not Qt's.
I haven't been able to confirm that, unfortunately. At least partially due to the fact that I don't really know the underlying cause, so I may not use the right search terms on StackOverflow or the Qt Bug list. If @jgr33nwood has any insights, I'd love to hear them. A decent workaround or a fix in my own code to get rid of this issue are both perfectly acceptable solutions to me.
just checking in in the new year :)
i might do some promotion of this issue on the gitcoin twitter and slack.. but let me know if i should not since @tiro6090 is already on it (or for another reason)
Hi @tiro6090 @TimVanMourik I recently joined @owocki at Gitcoin... Checking in on this one to see if @tiro6090 is on it / we should pub this out to the Gitcoiners!
Thanks @vs77bb, some advertising would be much appreciated! The bug seems quite persistent and not easy to solve. I can't increase the bounty post-hoc, but I'd happily add an additional tip to a total bounty of 0.15 ETH, by the way.
@TimVanMourik Just sent it out on our Slack - mentioned the the tip as well!
Hi @lmirza3 - Could you let us know your approach for this one? Looking forward to seeing your efforts here!
hey @TimVanMourik from gitcoin!
we are in the middle of a migration between smart contracts and in order to migrate away from all the old code paths, we are cleaning up some of the straggler bounties.
we're sorry this one didnt work out!
do you want to kill the bounty here to recover your funds?
any questions, let me know! KSO
Hi @owocki! Yes, the problem seemed to be somewhat more complicated than I anticipated. Better luck next time. And thanks to everybody that looked into the issue! I killed the bounty, thanks for the link.