#pyqt | Logs for 2019-02-23

Back
[00:11:49] -!- storgance has quit [Ping timeout: 256 seconds]
[03:19:01] -!- a-l-e has joined #pyqt
[08:14:00] -!- mintograde has joined #pyqt
[13:12:15] -!- ntome has joined #pyqt
[13:12:17] <ntome> hello
[13:12:48] <ntome> in c++, qbuffer seems to take a pointer to qbytearray and doesn't copy it
[13:13:08] <ntome> in python, should i hold a ref to the qbytearray if i don't want my qbuffer to crash?
[15:04:03] -!- Safa_[A_boy] has joined #pyqt
[15:04:11] <Safa_[A_boy]> Any help? :) https://forum.qt.io
[15:39:46] <altendky> Safa_[A_boy]: when you open you could chop into the individual components and reassemble on save
[15:43:16] <altendky> Think of it like a zip file. You wouldn't want each text editor for each file in the zip to be carrying around the entire unpacked zip archive
[15:46:51] <Safa_[A_boy]> So, change the whole design? :)
[15:47:28] <Safa_[A_boy]> That's possible yes, but then I have to do this in Python side, which is less easier than QML side
[15:48:04] <Avaris> Safa_[A_boy]: those don't say much about how you use the image
[15:50:54] <altendky> Does a repeater create multiple copies?
[15:51:03] <altendky> Of the MyImage?
[15:52:42] <altendky> It looks like it would based in the nowX and nowY assignments
[15:52:53] <Avaris> also, i suspect each "Item" reads and stores the whole image
[15:53:09] <altendky> So if the image were loaded once somewhere and then shared (maybe in Python...)
[15:54:45] <altendky> But yeah, I never really like leaving having everything everywhere deal with... Whatever we want to refer to these Sprite sheets as. Seems like only load and dump should have to be aware of that
[16:01:05] <altendky> Avaris: did you see the resolution last night? Though I still don't like what I have. I think I should parent the widget to the view and maybe even set it's position before drawing
[16:01:35] <altendky> I ended up with finding the top level window and then mapTo to get the offset
[16:11:31] <Avaris> altendky: sort of. i don't get it though. you shouldn't need to do that
[16:12:14] <Avaris> (unless render does funky stuff to painter)
[16:12:55] <Avaris> it's coordinate system should be inside of the view. 0,0 -> topLeft etc.
[16:13:21] <altendky> Avaris: I figure the unparented widget is drawing at 0,0 which is taken relative to the top level widget. I didn't did in detail but I'm not sure such things are clarified, and unparented widgets rendering... Might be undefined
[16:14:19] <Avaris> painter is the weird one here
[16:15:24] <Avaris> maybe you can try qwidget.grab to a QPixmap and paint that. i suspect render is modifying the painter in some way
[16:16:15] <altendky> Avaris: you think it'd be bad to parent the widget?
[16:16:47] <altendky> You pass a factory into the delegate so nothing else even has the widget instance
[16:16:51] <Avaris> umm, it's going to be visible then...
[16:17:26] <altendky> Avaris: even if you hide it?
[16:17:54] <Avaris> well, no but i don't think parenting is the issue
[16:18:50] <altendky> I just figured that the (assumed) 0,0 would end up being at the list view origin then and avoid searching up the tree for the window
[16:18:59] <Avaris> either i'm grossly misunderstanding what render does but somehow painter's internal coordinate system is messed up at some point, i think
[16:22:19] <Avaris> pixmap = self.widget.grab(); painter.drawPixmap(option.rect, pixmap, pixmap.rect())
[16:22:25] <Avaris> this looks fine
[16:22:55] <Avaris> less ideal, though. now there is a pixmap in the middle :)
[16:23:38] <Safa_[A_boy]> It's a 1024x1024 image, having sub images. I have a table with values that I use to set x, y, width and height to clip it (using another parent Item to Image)
[16:24:18] <Safa_[A_boy]> And it seems that each Image instance is allocating it's own memory, which is the problem I'm solving here
[16:25:10] <Safa_[A_boy]> And I use the full image because the user can modify that table with new values, whoever he wish. So a full image with changing x/y/width/height is better than cropping again in Python side
[16:25:58] <Avaris> yeah, but how do you crop?
[16:26:07] <Avaris> create new pixmap/images?
[16:26:58] <Safa_[A_boy]> Item's clip? :)
[16:27:10] <Safa_[A_boy]> ( :P )
[16:28:10] * Avaris hates QML
[16:28:29] <Avaris> so... you get the full image, move it around and show only part of it?
[16:28:45] <Safa_[A_boy]> I understand you, but it's great to program with. I talk about the new UIX things going on
[16:29:09] <altendky> I think we're back to painting (part of) a pixmap :]
[16:29:11] <Safa_[A_boy]> Yes, exactly. I just show it all, and clip "hides" the outside parts
[16:29:26] <Safa_[A_boy]> Like a mask let's say
[16:29:48] <Avaris> sounds inefficient :)
[16:30:10] <altendky> Safa_[A_boy]: but if there online that's applying the crop holds the whole image... I mean changed to one part won't even show up in the other parts
[16:30:27] <altendky> It's really a mess every time Sprite sheets come up it seems
[16:30:42] <altendky> No abstraction from it at any level
[16:31:10] <Safa_[A_boy]> Avaris, Yes, I know. But no time for too much work in the Python side. At the end it's a tool for a friend. Have other things to care for
[16:31:33] <Avaris> make him but more ram :P
[16:31:36] <Avaris> *buy
[16:32:27] <Safa_[A_boy]> Nice solution, too. He might also not use the tools at all. (Perfect solution)
[16:32:30] <altendky> Safa_[A_boy]: the sheet is like a zip file. You wouldn't make each widget handle the entire zip, you would extract the part you needed
[16:33:05] <Avaris> seriously though, not sure what's wrong. QML Image says it caches images with same source. so in the end you shouldn't get more than one image read
[16:33:37] <altendky> Deal with each Sprite separately and pack and unpack from the sheet
[16:33:52] <Safa_[A_boy]> altendky, I've said that you can edit the table associated with the sheet, meaning I don't want to give/take things between QML and Python with every single signal
[16:34:35] <altendky> Safa_[A_boy]: yes. I'm saying that the way people handle Sprite sheets is silly.
[16:34:37] <Safa_[A_boy]> Avaris, I would have opened a bug, but I'm not sure how caching works. So it's not that useful
[16:35:09] <altendky> It's a bunch of _separate_ images that get archived into a single image file
[16:35:34] <Avaris> i mean, this is what it says. literally... "Images are cached and shared internally, so if several Image items have the same source, only one copy of the image will be loaded."
[16:35:36] <Safa_[A_boy]> altendky, Well, you have to live on with this world :D
[16:35:57] <altendky> Safa_[A_boy]: doesn't mean I can't encourage people to abstract sensible
[16:36:00] * Safa_[A_boy] got an idea..
[16:36:02] <altendky> Sensibly
[16:38:02] <Safa_[A_boy]> Nope, nothing changed (I just disabled clip to see if it's the cause)
[16:38:22] <Avaris> do you modify the image?
[16:38:37] <Safa_[A_boy]> Like pixel-wise? no.
[16:39:26] <Avaris> did you try sourceSize?
[16:40:05] <Safa_[A_boy]> Well, I can change the sourceSize in two Images, but I need the real size for the repeater :S
[16:40:35] <Avaris> no i meant setting the actual size.
[16:42:06] <altendky> Safa_[A_boy]: what version of pyqt?
[16:42:18] <Avaris> also, were you able to identify what action is causing memory increase?
[16:42:34] <Safa_[A_boy]> Latest from pip, 5.12?
[16:42:41] * Safa_[A_boy] checking sourceSize
[16:48:51] <Safa_[A_boy]> sourceSize didn't change anything, RAM still increases.
[16:49:32] <Avaris> by doing what though?
[16:50:01] -!- a-l-e has quit [Remote host closed the connection]
[16:50:15] <Safa_[A_boy]> For the Repeater I have, it's inside a flow. And I have a text input. I send the text to the Python side, parse and send back the indexes in the model to display them. With this, the ram was increasing a lot (maybe because I'm resetting the Repeater's model property)
[16:50:27] -!- a-l-e has joined #pyqt
[16:51:00] <altendky> It's old, but https://forum.qt.io
[16:51:04] <Safa_[A_boy]> I tried with a fixed model value, and it resulted in less RAM usage, but still more than what it should be (3 times more
[16:51:08] <altendky> Maybe search for other bugs
[16:51:49] <Safa_[A_boy]> "
[16:51:49] <Safa_[A_boy]> The bug is related to https://bugreports.qt.io and I confirmed that this patch fixes the problem: https://codereview.qt-project.org
[16:51:49] <Safa_[A_boy]> "
[16:51:53] * Safa_[A_boy] sorry
[16:52:41] <Safa_[A_boy]> I'll try something with qmlscene and if I replicate it, I'll report it
[16:53:15] <Safa_[A_boy]> Thanks a lot, Avaris and altendky =)
[16:53:53] <altendky> Safa_[A_boy]: good luck
[17:01:30] -!- a-l-e has quit [Ping timeout: 250 seconds]
[17:10:56] -!- Safa_[A_boy] has quit [Quit: Leaving]
[18:02:23] -!- n1` has quit [Ping timeout: 268 seconds]
[18:05:39] <altendky> parenting and hiding doesn't seem to be having any affect...
[18:23:03] <altendky> yeah, all i managed to 'improve' was caching a null qregion on self to avoid reconstruction each paint... :|
[18:27:38] <altendky> oh, well i can at least drop the while loop with https://doc.qt.io
[18:40:35] -!- kushal has quit [Remote host closed the connection]
[18:40:55] -!- kushal has joined #pyqt
[18:51:12] <altendky> so, how would you write tests for a delegate like this? use a widget that paints a png and has fixed size hint and then grab the list view and compare to a reference image?