#pyqt | Logs for 2020-07-11

Back
[01:49:20] -!- honigkuchen has quit [Remote host closed the connection]
[02:03:21] -!- oprypin has quit [Ping timeout: 256 seconds]
[02:06:16] -!- JanC has quit [Read error: Connection reset by peer]
[02:06:28] -!- JanC has joined #pyqt
[02:14:29] -!- cottoneyejim has joined #pyqt
[05:33:42] -!- iTommix has joined #pyqt
[06:59:36] -!- SpinTronix has joined #pyqt
[07:33:44] -!- frispete has quit [Remote host closed the connection]
[07:34:58] -!- frispete has joined #pyqt
[08:55:14] -!- sazawal has joined #pyqt
[08:57:02] -!- cottoneyejim has quit [Ping timeout: 260 seconds]
[09:05:28] -!- honigkuchen has joined #pyqt
[09:09:15] -!- cottoneyejim has joined #pyqt
[10:32:40] -!- sazawal has quit [Quit: Leaving]
[10:34:50] -!- BPL has joined #pyqt
[10:35:25] -!- honigkuchen has quit [Remote host closed the connection]
[10:37:10] -!- cottoney1 has joined #pyqt
[10:39:26] -!- cottoneyejim has quit [Ping timeout: 256 seconds]
[11:00:38] -!- cottoney1 has quit [Ping timeout: 272 seconds]
[11:02:28] -!- iTommix has quit [Quit: iTommix]
[11:22:32] -!- sazawal has joined #pyqt
[12:05:34] -!- frispete has quit [Ping timeout: 260 seconds]
[12:08:19] -!- cottoney1 has joined #pyqt
[12:11:38] -!- frispete has joined #pyqt
[12:17:42] -!- Belxjander has quit [Ping timeout: 260 seconds]
[12:20:08] -!- Belxjander has joined #pyqt
[12:29:37] -!- cottoney1 has quit [Ping timeout: 264 seconds]
[12:36:40] -!- frispete has quit [Remote host closed the connection]
[12:37:23] -!- frispete has joined #pyqt
[12:43:06] -!- cottoney1 has joined #pyqt
[12:44:46] -!- iTommix has joined #pyqt
[13:13:19] -!- cottoney1 has quit [Ping timeout: 246 seconds]
[13:27:04] -!- cottoney1 has joined #pyqt
[13:51:24] -!- SpinTronix has quit [Quit: Konversation terminated!]
[13:53:42] -!- SpinTronix has joined #pyqt
[15:13:09] -!- iTommix has quit [Quit: iTommix]
[15:26:31] -!- sazawal has quit [Quit: Leaving]
[16:36:19] -!- cottoney1 has quit [Ping timeout: 246 seconds]
[17:18:21] -!- frispete has quit [Remote host closed the connection]
[17:20:13] -!- frispete has joined #pyqt
[17:51:32] <ali1234> i want to make a widget that looks like the old defrag display, where you have small rectangles of different colours. any suggestions where i should start?
[17:51:55] <ali1234> i want it to be interactive... each rectangle should be clickable and some kind of highlight
[18:05:29] <ali1234> hmm maybe i dont need it
[18:10:10] <Avaris> one obvious answer is (a lot of) QPushButtons :)
[18:10:32] <ali1234> i'll need something like a quarter million of them (it needs to scroll as well)
[18:10:55] <Avaris> i don't envy the person who needs to click them
[18:10:59] <ali1234> yeah
[18:11:10] <ali1234> it's for categorisation of a large dataset
[18:11:22] <ali1234> i need a quick and dense way to navigate it
[18:11:56] <ali1234> i need to look at 7 million time series and categorize each one as "interesting" or not
[18:13:05] <Avaris> it'll be probably easier to formulate what "interesting" is and automate that
[18:13:14] <ali1234> that is what i am tryng to do
[18:13:27] <ali1234> i want to train an AI to do it... for that i need a training set
[18:13:42] <ali1234> to make the training set i need a decent UI that can navigate the data efficiently
[18:13:50] <ali1234> at the moment the UI looks like this: https://cdn.discordapp.com
[18:13:59] <ali1234> green = interest, red = not interesting
[18:14:05] <ali1234> problem is, it's not accurate enough
[18:14:37] <altendky> 250k things to click on?
[18:14:57] <ali1234> each recording has about 8 million lines (you see 32 in the screenshot)
[18:14:58] <Avaris> is that one (training) data point? or a row of them? or a grid of them?
[18:15:01] <altendky> mm, only 3 days at one per second
[18:16:39] <Avaris> import gather_a_bunch_of_friends as multiprocessing
[18:16:48] <ali1234> yes i have already done that :)
[18:16:57] <ali1234> now we need a UI to actually do the work
[18:17:40] <ali1234> due to the nature of the data, there are some ways to optimize it, eg if line 0 is not interesting, then it is very likely that line 0+32 will not be interesting either
[18:18:16] <ali1234> so i plan to show line 0, 32, 64... all on one page with a button that says "all these lines are the same"
[18:18:21] <ali1234> that should greatly accelerate it
[18:18:53] <Avaris> how many points per row?
[18:19:04] <ali1234> how many samples?
[18:19:24] <ali1234> or you mean the defrag viewer thing?
[18:19:41] <Avaris> so 32 is a page i guess... that is 32 by what exactly?
[18:19:53] <ali1234> depends on what hardware you used to capture it
[18:20:02] <ali1234> but somewhere between 2048 and 3500
[18:20:35] <ali1234> also sometimes the pages are 34 tall... again, depends what hardware you used
[18:20:54] <ali1234> in that case lines 0 and 17 will *always* be not interesting
[18:21:52] <ali1234> also 8 million lines is just one fill recording and i have like a hundred
[18:22:13] <ali1234> 8 million lines is how big each file is
[18:22:37] <Avaris> is that 8mx32 or 8m/32?
[18:23:12] <ali1234> what you see in the screenshot is one frame. each frame has 32 lines (16 per field, it is interlaced video)
[18:23:43] <ali1234> there are 25 frames per second, and each recording is 3 or 4 hours long
[18:23:47] <Avaris> so, 8m/32 frame?
[18:23:51] <ali1234> yes
[18:23:55] <ali1234> approximately
[18:24:25] <Avaris> and you'll be doing this frame by frame? possibly a couple frames each time?
[18:24:31] <ali1234> i have around 100 recordings, other people actually have more than me
[18:24:57] <ali1234> my plan is to take the first line of N sequential frames, because it is very likely they will all have the same contents
[18:25:02] <ali1234> then do the second line, then the third etc
[18:25:33] <ali1234> where N = however many i can fit on screen and still be able to see them, so probably like 64
[18:26:13] <ali1234> so then in the defrag style view, each block will represent 64 lines, the view will be 32 tall and 8million/(64*32) wide
[18:27:06] <ali1234> grey = unknown, red = all not interesting, green = all interesting, yellow = mixed etc
[18:27:22] -!- honigkuchen has joined #pyqt
[18:27:46] <ali1234> this same UI could also be used to quickly check whether the automatic classifier matches manual classification, and quickly find lines that it misclassified
[18:27:52] <ali1234> at least that is the idea
[18:28:52] <Avaris> ah, ok so you'll be doing first line of all frames, second line, etc... i thought you were going this frame by frame
[18:28:54] <altendky> so each cell is going to be a video frame the person can see?
[18:30:16] <ali1234> kind of
[18:30:32] <ali1234> each cell will be 64 lines, but they will be from different frames (what avaris said)
[18:31:27] <ali1234> so you'll look at it and be able to say "these are all good" or "these are all bad" instead of having to do each line separately
[18:32:37] <ali1234> let me up a video, it's easier to understand when you see it
[18:32:42] <Avaris> and in this 32xM view, you want colors per cell and... click to investigate that stack?
[18:32:48] <ali1234> yes
[18:33:16] <ali1234> it needs to show which ones you've already done, plus what you can expect in the ones you haven't done
[18:33:47] <Avaris> qgraphicsview might be the most efficient one for that
[18:34:01] <Avaris> "what you can expect"?
[18:34:13] <ali1234> yeah, from the automatic classifier
[18:34:21] <ali1234> which is pretty good but not perfect
[18:34:35] <ali1234> see https://www.youtube.com
[18:34:42] <Avaris> oh, i thought you wanted like a thumbnail preview or something :)
[18:35:00] <ali1234> nah, just like "did the classifier detect any rows at all here"
[18:35:18] <ali1234> if you watch the third from last row in that video, you can see sometimes the classifier gets it wrong
[18:35:32] <ali1234> also there are valid rows that occasionally pop up in weird places
[18:35:42] <Avaris> green flicker?
[18:35:47] <ali1234> yeah
[18:36:43] <ali1234> so basically i just want like a 5x5 square where the colour carries the meaning
[18:37:08] <Avaris> that's the frame view though, right? not the first row of many frames thing?
[18:37:20] <ali1234> the video i uploaded is the frame view, yes
[18:38:02] <ali1234> you can see how some lines are always good, some are always bad, some are always bad but occasionally misclassified, and some are a mixture of good and bad
[18:39:25] <ali1234> my plan is something like, green = all good, red = all bad, yellow = mixture, and use light and dark to indicate sets that have been inspected or not (so already inspected would look faded, or maybe the other way around)
[18:40:20] <Avaris> i would go with qgraphicsview with the summary view thingy. 5x5 square with color is easy, click detections should be somewhat straightforward and should scale reasonably well for the 10000s of of those squares. plus built in scroll
[18:41:01] <ali1234> okay, i'll look into it, thanks
[18:41:42] <ali1234> i realise i'm making a UI that is completely incomprehensible to most people, but it will only have like 5 users and they are all very very familiar with the underlying data
[18:42:07] <ali1234> so i want to make it as efficient as possible, due to the large data volume that must be processed. no worry about making it "friendly"
[18:43:51] <Avaris> it can be both :)
[18:45:32] <ali1234> the ultimate goal here is to recover all teletext ever broadcast - that represents about 4 trillion lines
[18:45:55] <ali1234> (10^12 is a trillion right?)
[18:48:12] <ali1234> it would take my computer 31 years to process it all, but moore's law...
[18:49:39] <ali1234> alternatively throw a DGX A100 at it and it would be done in like 3 years
[18:51:38] <ali1234> i did get some interest from researchers with that type of hardware available to them... but the problem was no budget to pay someone to load tapes into a VCR
[18:56:11] <ali1234> the first version of this software 10 years ago would take over a week to do 8 million lines. now it take 30 minutes
[18:56:42] <ali1234> the big problem now is accuracy
[19:13:43] <altendky> i still don't have a clue what this means or how looking at the prediction of good or bad will help me decide if it is correct or not. and if the third to last row is always bad...
[19:14:45] <ali1234> the third to last row is always bad in the sample video, but sometimes the automatic classifier thinks it is good and so it gets drawn in green
[19:15:02] <ali1234> i need a way to tell it that it is wrong, basically
[19:15:51] <altendky> sure
[19:15:52] <ali1234> having an overview of the whole file helps because a file can contain multiple shorter recordings (different programmes recorded on one tape) and looking at the preview will allow to quickly find the boundaries
[19:15:57] <altendky> but how do i know it is wrong?
[19:16:06] <ali1234> you just know from looking at the full size data
[19:16:24] <altendky> other than all the other times it is red and it picked green once. which is like, just... if it's 90% red then mark the other 10% red too...
[19:16:41] <ali1234> but that will be wrong :)
[19:16:48] <altendky> how is it i know that?
[19:16:54] <ali1234> well, look at this https://cdn.discordapp.com
[19:17:05] <ali1234> in this picture every line was correctly classified
[19:17:26] <altendky> how do we know that?
[19:18:08] <ali1234> well look at all the green lines. see how they all start with the same pattern, a long grey bit, then a short white bit, then something that looks like a barcode
[19:18:33] <ali1234> the lines are in reality all greyscale, and they are tinted according to the classifier output
[19:18:41] <ali1234> they aren't actually red or green in the recording :)
[19:19:04] <altendky> ok, so the data is the brightness
[19:19:11] <altendky> the hue is the guessed good or bad
[19:19:19] <ali1234> conversely the red lines: some are completely empty, one has that gradient towards the rhs
[19:19:37] <ali1234> the otherone looks barcode-y but it doesn't have the right pre-amble - it's probably wide screen signalling or something
[19:20:03] <altendky> so 'good' is 'similar brightness pattern to other rows'?
[19:20:31] <ali1234> not always
[19:20:35] <altendky> :]
[19:20:37] <altendky> so what is it?
[19:20:38] <ali1234> sometimes there is only one good row in a frame
[19:20:51] <ali1234> "good" is "line contains something that looks like a teletext signal"
[19:21:06] <altendky> ok
[19:21:10] <ali1234> teletext signals look like the green lines *in this sample*
[19:21:27] <altendky> i see the common vertical bars throughout the green
[19:21:38] <ali1234> but different broadcasters, different recorders, different quality tapes, different capture cards... all mess it up... a lot
[19:21:42] <altendky> i see dim start, then bright block with a ridge at the right
[19:21:53] <altendky> and then the bars in the dim
[19:22:00] <ali1234> that pre-amble goes 101010101010101011100100
[19:22:04] <altendky> and then miscelannious not dim that's not particularly identifiable
[19:22:05] <ali1234> but it is smeared by VHS
[19:22:26] <ali1234> the rest of the data is completely different in each packet
[19:22:36] <ali1234> there's no other fixed bits in the signal other than the ones at the start
[19:22:53] <ali1234> it is actually really easy for a human to spot the teletext lines, but surprisingly hard to make a computer do it
[19:24:01] <altendky> it seems it shouldn't be a huge deal to identify that start region
[19:24:13] <altendky> the bars should show up in a frequency analysis
[19:24:17] <altendky> for most of them
[19:24:20] <ali1234> they do
[19:24:23] <ali1234> and i do that :)
[19:24:32] <ali1234> i FFT it, and look for certain frequencies
[19:24:48] <ali1234> and it works fairly well, but it can still get tricked
[19:25:12] <altendky> does it get false negatives?
[19:25:15] <altendky> or just positives?
[19:25:17] <ali1234> so what i really need is a large dataset that has been manually labelled, so i can properly test the accuracy of various algorithms, maybe do ML etc
[19:25:27] <ali1234> it gets false positives and negatives
[19:26:13] <ali1234> at the moment i'm kind of just blindly trying things and looking at the output, and i have no way to really scientifically judge if this is an improvement. i can be an improvement for some tapes, an worse for others
[19:26:42] <ali1234> and running all 100 tapes through the new algorithm would take a week
[19:26:51] <ali1234> so... i need to draw samples from all tapes
[19:27:00] <altendky> what is the algorithm coded in?
[19:27:07] <ali1234> and especially ones that the current algorithm misclassifies... so i need to find those quickly
[19:27:16] <ali1234> the algorithm is coded in numpy and CUDA
[19:27:52] <ali1234> so if i have this preview system... i can look for blips in the preview to quickly find misclassified lines
[19:28:07] <ali1234> add them to the sample set and re-run etc
[19:28:22] <altendky> did you create this image?
[19:28:29] <ali1234> which image?
[19:28:30] <altendky> /video
[19:28:32] <ali1234> yes
[19:28:36] <altendky> the stuff you've been linking
[19:28:47] <ali1234> yes, i created the image, and the software :)
[19:29:02] <altendky> so you just need to detect the click and location and know what you drew there
[19:29:14] <ali1234> pretty much, i mean, i could code it in opengl
[19:29:36] <ali1234> but i dont want to deal with scrolling and etc... its a bit low level, you know?
[19:29:40] <ali1234> the current tool is opengl
[19:29:42] <altendky> i guess i'm not seeing the big problem. you are already showing it. presumably in a click event you could decide which row was clicked based on coordinates, right?
[19:29:53] <ali1234> yes i can already do that
[19:30:01] <ali1234> it's the preview bit i was asking about
[19:30:11] <ali1234> the current software does not have any preview
[19:30:27] <ali1234> it would be another widget, above the line display, to quickly move about in the file
[19:30:39] <ali1234> the current software can onlyplay all lines sequentially in order and that takes too long
[19:30:43] <ali1234> you can't rewind even
[19:31:13] <ali1234> like, imagine a video editor where you have the picture, and a timeline to navigate around
[19:31:21] <ali1234> currently i have the picture but not the timeline
[19:31:28] <altendky> sure
[19:31:35] <altendky> i'm not sure what the timeline would look like
[19:31:58] <ali1234> it would look like the disk defrag widget from windows 95 :)
[19:32:10] <altendky> what you have already 'looks like that'
[19:32:15] <ali1234> no it doesn't
[19:32:26] <altendky> sure it does... it's a bunch of little boxes
[19:32:53] <altendky> how does https://cdn.discordapp.com get mashed down into other little boxes?
[19:33:02] <ali1234> hah... everything is a bunc of littleboxes if you get close enough to the screen :)
[19:33:18] <ali1234> so that image is one frame
[19:33:35] <ali1234> you would take, say, 64 frames
[19:33:55] <ali1234> then if every line 0 from every frame is green, then the little box at 0, 0 would be green
[19:34:08] <ali1234> if every line 0 is red then the box is red
[19:34:17] <ali1234> if the lines are a mix of red and green, then the box is yelow
[19:34:33] <ali1234> then repeat for all line 1 -> box at 0, 1
[19:34:41] <ali1234> repeat for all lines and you have the first column of boxes
[19:34:56] <ali1234> then you take frames 64 to 127 and they are the next column
[19:35:14] <altendky> so there are cases where 99% of row 3 is green and 1% is guessed red... but half of those 1% are correctly red and half incorrectly?
[19:35:27] <ali1234> that is possible yes
[19:35:40] <ali1234> it will be more like: 99% of boxes will be red or green
[19:35:45] <ali1234> you click on it and see all the lines
[19:35:55] <altendky> but that's an indication that a human should look at it to double check those 1%
[19:36:02] <ali1234> you can very quickly tell if they are in fact all correct or not, and click one button... now that subset of the data is done
[19:36:17] <ali1234> however if a box is yellow, then you need to spend more time on it, yes
[19:36:35] <altendky> seems a bit presumptive around the edges
[19:36:54] <ali1234> well i won't know until i code it... but trust me iv've been doing this for 10 years :)
[19:37:06] <ali1234> i know what the signals look like, and how they are structured
[19:37:13] <altendky> i mean you are putting in arbitrary boundaries at 64 frames right?
[19:37:19] <ali1234> sure
[19:37:23] <altendky> so let's say the first 60 are green
[19:37:27] <ali1234> 64 frames is like 2 and a bit seconds
[19:37:30] <altendky> then a red, a green, a red, a green
[19:37:35] <altendky> so there's 64
[19:37:38] <ali1234> then the box is yellow
[19:37:41] <altendky> sure
[19:37:48] <altendky> now the next set of 64 are all green
[19:37:53] <altendky> shouldn't i be looking at them too?
[19:37:56] <altendky> at least the first few
[19:38:08] <ali1234> the way teletext is broadcast is that the broadcaster picks some subset of the available lines to use and then they will *always* be data on those lines
[19:38:33] <ali1234> but you can't just assume that for a whole tape because there might be different channel recordings
[19:38:34] <altendky> box 2 frames 0,1,2 are just as close to the questionable data as box 1 frames 57, 58, 59
[19:38:44] <ali1234> but a recording is almost certainly going to be longer than 2 seconds
[19:38:59] <altendky> but because of this arbitrary boundary at 64 you look at box 1 and not box 2
[19:39:05] <ali1234> 64 is a number picked because that's how many lines you can comfortably display an dstill be able to understand them with your eyes :)
[19:39:06] <altendky> or is that not what would hapen
[19:39:47] <ali1234> ultimately you should look at every set of data
[19:40:29] <altendky> i'm imagining that instead of quantizing the data every 64 you just calculate it all out and then identify some changes around 62 and it gets indicated for review from 55 to 69
[19:40:34] <ali1234> but sometims you might be looking specifically for misclassified lines... and you will find one quicker if you go to yellow blocks
[19:40:56] <altendky> right, but exactly adjacent but in a green block there is just as likely an error
[19:40:58] <ali1234> there is no quantization
[19:41:07] <altendky> you are blocking into 64 and grouping them
[19:41:08] <ali1234> no, that's not really true
[19:41:23] <ali1234> they are grouped, but not quantized in any way
[19:41:30] <ali1234> the are just grouped for convenience
[19:41:37] <altendky> in my example, box 2 line 1 is just as likely an error as box 1 line 58
[19:41:46] <altendky> but only box1 will get reviewed because only it is yello
[19:41:47] <altendky> w
[19:41:59] <altendky> or, will you also end up looking on forward into the next?
[19:41:59] <ali1234> i mean i could have no grouping but then the scroll widget is going to be 64 times longer and contain 8 million boxes instead of 250000
[19:42:16] <altendky> or
[19:42:18] <ali1234> all blocks will be reviewed
[19:42:19] <altendky> it's 'continuous'
[19:42:42] <ali1234> there are two different ways i see the program being used:
[19:42:50] <ali1234> one is to build a large dataset of classified lines
[19:43:05] <ali1234> you can do that quickly by looking at red and green blocks and clicking the "yes they are all the same" button
[19:43:10] <altendky> and rendered to pixels and you let the areas that change back and forth be questionable regardless of boundaries at multiples of 64
[19:43:20] <ali1234> the other way is looking specifically for misclassified lines, and you can find those quickly by looking in the yellow blocks
[19:43:42] <altendky> i just don't see the need to create the blocks
[19:43:54] <ali1234> i literally just explained it :)
[19:44:17] <altendky> there are changes in my example from 60 to 64. who cares about it being right before a 'boundary'
[19:44:22] <altendky> i also literally explained how it isnt needed
[19:44:24] <ali1234> the software will track which blocks have been reviewed, and what they truly contain
[19:44:25] <altendky> literally
[19:44:43] <ali1234> so you won't be wasting your time looking at already reviewed blocks
[19:44:54] <altendky> yup... my suggestion doesn't lose that?
[19:45:01] <altendky> just i don't have blocks
[19:45:14] <altendky> there's stuff triggering yellow at 60 through 64
[19:45:14] <ali1234> okay what do i have instead then? just a continuous line?
[19:45:24] <altendky> so, instead of showing me 0 through 64 and not 65 through 128
[19:45:40] <altendky> show me 40 through 80 or whatever
[19:45:57] <ali1234> okay but what if there is a line that switches between red and green every frame?
[19:46:00] <altendky> because then i'm looking on _both_ sides of the questionable data rather than just one
[19:46:07] <ali1234> now the scroll widget is going to be super wide
[19:46:11] <ali1234> and only for that line
[19:46:21] <altendky> none of what i said affects how wide things are
[19:46:39] <altendky> and either way that'll make everything yellow
[19:46:47] <ali1234> yes
[19:46:50] <ali1234> it will
[19:46:53] <ali1234> but only for that line
[19:47:03] <ali1234> and it will be real obvious from the preview window
[19:47:09] <altendky> basically i'm saying toolz.sliding_window rather than toolz.partition
[19:47:25] <altendky> so you avoid arbitrary irrelevant boundaries
[19:48:47] <ali1234> so... if you dont ever look at a block, then it will never be marked as reviewed
[19:48:58] <ali1234> it doesn't really matter how they are grouped
[19:49:10] <ali1234> the idea is to categorize as quickly as possible
[19:49:22] <altendky> why are you telling me to look at certain ones if i'm going to look at them all anyways?
[19:49:35] <ali1234> i'm not telling you what to look at
[19:49:46] <ali1234> i'm telling you what you'll see if you look, before you actually look
[19:49:47] <altendky> ok
[19:50:02] <altendky> everything i've said is improving what you encourage people to look at
[19:50:10] <ali1234> cos seeking in the file and loading the data is actually relatively expensive
[19:50:26] <altendky> when you have questionable data at 60 through 64 it is probably more important to look at 64 than at 1
[19:50:30] <altendky> *65 than at 1
[19:50:43] <altendky> but your way seems to encourage me to look at 1 through 64 and not look at 65
[19:50:43] <ali1234> why?
[19:50:57] <altendky> because 65 is much closer to the questionable data than 1 is
[19:51:04] <altendky> it's 2 away rather than 59 away
[19:51:21] <ali1234> okay but if you look at 65 then you wont see any questionable data
[19:51:50] <altendky> so help the user look at 50 through 75 or whatever because there was questionable data at 60 through 65
[19:51:58] <altendky> 64, whatever...
[19:52:02] <ali1234> so variable sized groups?
[19:52:15] <altendky> figure out the indexes of questionable data
[19:52:32] <ali1234> the more important thing is that whole groups get marked as "reviewed"
[19:52:36] <altendky> sliding window for that avoids the arbitrary irrelevant boundaries you are placing every 64 frames
[19:52:40] <ali1234> and it needs to display that too
[19:52:59] <altendky> then... pick ranges that cover the questionable values plus some buffer each side.
[19:53:00] <ali1234> so you want something like an audio timeline, with zooming?
[19:53:03] <altendky> get those reviewed
[19:53:22] <altendky> maybe
[19:53:40] <ali1234> the problem with variable sized groups is that there can be a very large nuber of them
[19:54:21] <altendky> if anything i'm suggesting a thing that can possibly result in fewer blocks to review. it can't result in more
[19:54:23] <ali1234> on the other hand, the line display can only fit so many lines in it, a fixed number pretty much
[19:54:43] <altendky> that's the other axis
[19:54:47] <ali1234> plus you can only scan through so many lines without making an error
[19:54:57] <ali1234> no, the line display is not the other axis
[19:55:07] <altendky> https://cdn.discordapp.com
[19:55:16] <ali1234> the line display will not look like that
[19:55:25] <altendky> each row in that will be an independent row in your 'other' view, right?
[19:55:41] <ali1234> yes
[19:55:43] <altendky> so let's just talk about one since they are independent.
[19:55:55] <ali1234> and this view will not be present
[19:56:24] <ali1234> instead, the line display will show line N from frames X to X+M (where M might = 64)
[19:56:26] <altendky> now progressing through the 'other' view is going through the 'frames' of the first row in the link
[19:56:37] <ali1234> nope
[19:56:45] <ali1234> it's going through frame *groups*
[19:57:11] <altendky> which are a modification of going through the frames which i'm telling you is creating arbitrary unhelpful boundaries
[19:57:18] <altendky> but yes, we are talking about the same dimensions
[19:57:22] <altendky> just different groupins
[19:57:24] <ali1234> but the boundaries are not unhelpful... they are in fact helpful
[19:57:25] <altendky> gropuings
[19:57:39] <ali1234> because it is extremely likely that all consecutive frames have the same data on the same line
[19:57:40] <altendky> they arbitrarily encourage you to look at less important
[19:57:46] <altendky> data farther away from the questionable data
[19:57:55] <ali1234> all data is important, all data is questionable :)
[19:58:05] <altendky> then why are you guiding me to look at only some of it?
[19:58:10] <altendky> if i need to look at all of it
[19:58:22] <ali1234> i'm not telling you what to look at :)
[19:58:31] <ali1234> i'm telling you where to find whatever you want
[19:58:32] <altendky> then why are you creating this 'other' view at all?
[19:58:41] <altendky> if i'm going to ignore it, why code it?
[19:59:01] <ali1234> i'm not going to ignore it :)
[19:59:25] <altendky> right, so you are creating it to encourage someone to pay attention to some of the data more than the rest
[19:59:33] <ali1234> nope
[19:59:41] <altendky> then why are you highlighting stuff
[19:59:51] <altendky> hey look, this is highlighted, don't care that it is highlighted, but it is
[20:00:07] <ali1234> only the current group will be highlighted
[20:00:09] <altendky> what is the point of highlighting if not to encourage people to pay attention?
[20:00:20] <ali1234> groups you have alread reviewed will have a fade effect
[20:00:26] <ali1234> the actual colour just indicates the contents
[20:00:28] <altendky> you said the groups with non-constant predictions will be highlighted
[20:00:30] <altendky> not the 'current'
[20:00:41] <ali1234> no, they won't be highlighted, they will just be a different colour :)
[20:00:52] <altendky> which is
[20:00:53] <altendky> exactly
[20:00:55] <ali1234> yellow
[20:00:56] <altendky> to show
[20:00:58] <altendky> something
[20:00:59] <altendky> being
[20:00:59] <ali1234> because red + green = yellow
[20:01:01] <altendky> different
[20:01:10] <altendky> which is there to help people focus in on that data over other data
[20:01:18] <altendky> otherwise, why color it at all
[20:01:22] <ali1234> no, that's not why it is there
[20:01:34] <altendky> then when i see red and yellow and green, why do i care?
[20:01:46] <ali1234> it depends what you are currently trying to do
[20:01:54] <altendky> that doesn't change anything
[20:02:01] <altendky> it's there to help provide an overview
[20:02:03] <ali1234> are you looking for the boundaries of different recordings? then look for a short burst of yellow on every row
[20:02:08] <altendky> which is done so you can decide where to go looking
[20:02:24] <ali1234> are you looking for a large amount of good lines, then look for a long run of green
[20:02:26] <altendky> if you aren't going to make any decisions based on the color, don't waste your time coloring
[20:02:36] <ali1234> are you looking for lots of bad lines? look for red
[20:02:52] <ali1234> are you looking for lines that fool the classifier, then look for long runs of yellow on a single line
[20:02:53] <ali1234> etc
[20:03:44] <ali1234> the thing is you wont ever want to deal with just 64 lines anyway
[20:04:01] <altendky> sliding window just avoids the arbitrary irrelevant boundaries. there's no reason to be coloring twice as much yellow when 63 of the 0-63 group and 64 of the 64-127 group are red and everything else is yellow than when 62 and 63 of 0-63 are red and all else is green
[20:04:20] <ali1234> a dataset for qualitive analysis is going to need several thousand lines at the minimum
[20:04:26] <altendky> a sliding window wouldn't care between those two cases. partitioning will
[20:04:41] <ali1234> how can you have a sliding window in a grid layout though?
[20:04:50] <altendky> you do it before
[20:04:52] <altendky> and forget the grid
[20:05:03] <altendky> and just indicate that 0.375% of the way through there's yellow
[20:05:08] <altendky> and again at 1.2993%
[20:05:10] <altendky> and so on
[20:05:10] <ali1234> what if line 60 to 64 on row 0 are bad, but line 23 to 29 are bad on row 1?
[20:05:21] <altendky> then sure, at some point it is rendered onto a screen of pixles
[20:05:45] <altendky> as i said before, we can talk about 1 row.
[20:05:58] <altendky> you've got 64 rows to be shown. so have 64 rows in your 'other' view too
[20:06:06] <ali1234> i need to see all rows at once, to spot things like recording boundaries
[20:06:13] <altendky> that's totally orthogonal to what we are talking about
[20:06:15] <ali1234> no there are 32 rows
[20:06:21] <altendky> ok, 32
[20:06:25] <ali1234> or 34 depending on hardware
[20:06:27] <altendky> it doesn't even matter how many
[20:06:36] <ali1234> the line view shows the same row from 64 different frames
[20:06:53] <ali1234> the point is to compress the X axis of the timeline preview
[20:07:03] <ali1234> otherwise it will be 250000 pixels wide
[20:07:49] <altendky> ok, utterly ignore me... i'm suggesting an _alternative_
[20:07:51] <ali1234> but by grouping i can make it 250000/64 * however big each block is
[20:07:59] <ali1234> i know you are suggesting an alternative
[20:08:06] <ali1234> but it doesn't work
[20:08:14] <altendky> that gives you something better and basically indistinguishable except that it guides you _around_ the actual points of interest
[20:08:20] <ali1234> if you don't group frames, then you can't fit enough information on screen to make the preview useful
[20:08:59] <ali1234> it is also harder to navigate, because every time you click you go to a different place unless you click on the exact same X pixel
[20:09:01] <altendky> you are talking like you are unaware of resampling, though i know you are
[20:09:39] <ali1234> i know what you want to do, you want to make a 250000 pixel image and then resample it into a 1000 pixel wide smudge :)
[20:09:48] <ali1234> this is not helpful :)
[20:10:07] <ali1234> the purpose of grouping into blocks is that they will be distinctive
[20:10:31] <ali1234> instead of a smudge, you get a definite green, red, yellow
[20:10:47] <altendky> You can still create that in the output without arbitrary boundaries
[20:10:59] <ali1234> that is true
[20:11:08] <altendky> Finally...
[20:11:08] <ali1234> but unless i implement zooming, there is no point
[20:11:40] <altendky> You would have to implement the idea for it to work. That's true of any idea.
[20:11:53] <ali1234> but, is there even any need for zooming?
[20:12:01] <ali1234> recordings are on average half an hour
[20:12:16] <ali1234> zooming in to the point where 1 frame = 1 pixel is just unnecessary
[20:12:26] <altendky> But either way I don't understand what part of drawing some pixels you are having trouble with
[20:12:35] <altendky> Especially given you are already drawing a bunch
[20:12:42] <ali1234> 64 frames < 2 seconds
[20:12:47] <altendky> I never suggested a pixel per frame
[20:13:23] <ali1234> if anything you would want to zoom out
[20:14:05] <ali1234> if the blocks are 5x5 with 1px spacing then 4 hour recording fits on screen when each block represents 1500 frames
[20:14:26] <ali1234> which = 1 minute
[20:14:27] <altendky> so it would fit either way...
[20:14:34] <altendky> none of this is different
[20:14:41] <ali1234> but then frames are in groups of 1500 which is even worse :)
[20:14:42] <altendky> but oh well
[20:16:12] <ali1234> but zooming introduces so much complexity, like how do you indicate which data has been inspected on the preview timeline?
[20:16:25] <ali1234> if the preview is fixed size regular blocks then it is easy
[20:16:39] <altendky> yes, there's likely a trade
[20:16:56] <altendky> but your thing is basing itself off of resolution which isn't super cool anymore
[20:17:08] <altendky> so you kinda end up dealing with not aligning with pixels no matter what
[20:17:20] <ali1234> a square is a square
[20:17:22] <altendky> or just have a crappy different experience based on dpi choices etc
[20:17:27] <ali1234> there will be spacing between the square
[20:17:31] <altendky> a video person ought to know that isn't true :]
[20:17:43] <ali1234> it doesn't matter if they are not actualy square :)
[20:18:02] <ali1234> the point is to have a reasonable thing to click on it with predictable behavior
[20:18:05] <altendky> basing your gui design around pixels is a troublesome thing these days
[20:18:15] <altendky> five pixels isn't a reasonable thing to click on
[20:18:24] <ali1234> not having to click around a yellow smudge inside a green-brown smudge to get what you want
[20:18:42] <altendky> they don't have to be smudges
[20:18:52] <altendky> that's a rendering choice
[20:18:58] <ali1234> they kind of do if you want it to be continuous
[20:18:59] <altendky> and sure, if you make bad choices it won't work well
[20:19:20] <altendky> yellow wins... don't smudge, just make the yellow area yellow
[20:19:24] <ali1234> this just sounds like it will be incredibly difficult to implement... however i am warming to the idea
[20:19:24] <altendky> even when you zoom out
[20:19:45] <ali1234> it would end up looking more like a traditional video editor, where you have rectangles of different lengths
[20:19:49] <altendky> i know that there is yellow at 1.9942% of the way
[20:19:54] <altendky> that's pixel 432
[20:19:55] <ali1234> hmm
[20:20:08] <altendky> so i draw a yellow box from 429 to 435
[20:20:13] <altendky> no smudge
[20:20:29] <ali1234> so when i click on the yellow box, what appears in the line view?
[20:20:49] <altendky> the middle frame of the questionable region?
[20:20:56] <altendky> and the 'other' view zooms to ...
[20:20:59] <ali1234> nah
[20:21:04] <ali1234> the line view never shows a single frame
[20:21:11] <altendky> who cares?
[20:21:13] <ali1234> it always shows one line from multiple frames
[20:21:15] <altendky> the view you have linked does
[20:21:25] <altendky> and that's what you are bringing up right?
[20:21:26] <ali1234> but that defeats the whole purpose of the software
[20:21:30] <altendky> so you have to pick one somehow
[20:21:38] <ali1234> no, i have to pick 64 frames
[20:21:41] <altendky> and then you will go forward and backward from there
[20:21:46] <ali1234> because the line view shows 64 lines
[20:21:55] <altendky> you said it was 32
[20:22:01] <altendky> or 34 depending
[20:22:02] <ali1234> no, a frame is 32 lines
[20:22:15] <ali1234> the line view shows 64 lines, each one is from a different frame
[20:22:26] <ali1234> so say frame 0 to 100 is a yellow box
[20:22:30] <ali1234> i click on that box
[20:22:37] <ali1234> which 64 frames do i select 1 line from?
[20:23:07] <ali1234> preferably they should be consecutive
[20:23:14] <altendky> https://cdn.discordapp.com is one frame with 32 rows?
[20:23:20] <ali1234> yes
[20:23:25] <altendky> so there are two other views?
[20:23:34] <ali1234> like i said, the thing i am making *will not have that vtype of display*
[20:23:36] <altendky> one is the 'everything' 'timeline' and the other is ...?
[20:23:54] <ali1234> the other is 64 *lines* from 64 consecutive frames
[20:24:03] <altendky> ok
[20:24:17] <altendky> well, you'll either pick the 'middle' 64 or the 'first' 64 or such
[20:24:20] <ali1234> so instead of selecting lines spacially, it selects them temporally
[20:24:39] <ali1234> but it needs to be able to display all lines in the recording somehow
[20:25:00] <altendky> so when i scroll up or down it does so one frame/row at a time
[20:25:14] <ali1234> no, there is no scrolling up and down
[20:25:25] <altendky> yes, i understand you haven't implemented my idea...
[20:25:31] <ali1234> only the timeline preview scrolls, and it does so horizontally
[20:25:45] <altendky> why don't the rows 'scroll' up and down accordingly?
[20:27:04] <ali1234> because it is too easy to miss a bad line when scrolling
[20:27:22] <ali1234> it is much quicker to just scan over one page and not have to worry about scrolling
[20:27:30] <ali1234> and then say "yep, this is okay"
[20:28:02] <ali1234> you dont need to move the mouse over to a scroll bar and look through many pages of lines
[20:28:11] <ali1234> then back to the "okay" button
[20:28:28] <ali1234> i plan to implement keyboard navigation to move through the timeline
[20:28:52] <ali1234> and for the okay button
[20:29:33] <altendky> who uses a scroll bar to scroll a little...
[20:29:44] <ali1234> ?
[20:30:11] <altendky> but anyways you are effectively 'scrolling' when you click the yellow right?
[20:30:16] <altendky> i use a scroll wheel to scroll
[20:30:23] <altendky> rarely do i touch scroll bars
[20:30:30] <ali1234> yeah. or press "right arrow" to move to the next group of 64 lines
[20:30:30] <altendky> and you 'other' view is basically a scroll bar
[20:30:45] <altendky> it can still jump by 64 for some cases
[20:30:47] <ali1234> the preview is the scroll bar
[20:31:17] <altendky> i'm just suggesting it doesn't have to be 0-63 then 64-127. it could instead by 27-whatever then 27+64-whatever
[20:31:25] <altendky> yes, so you still have a scroll bar
[20:31:32] <altendky> so don't argue that a scroll bar is stupid and terrible
[20:31:39] <altendky> because this is entirely about designing a scroll bar
[20:31:44] <ali1234> only 1 scroll bar though
[20:31:50] <ali1234> here is an example
[20:31:58] <altendky> i don't need an example of a scroll bar
[20:32:10] <ali1234> you know in atom (the code editor) the skeleton view at the rhs?
[20:32:19] <altendky> don't use atom
[20:32:24] <ali1234> pycharm has it too
[20:32:43] <altendky> and somehow, despite working on a 100k line file... you don't get smudges in it. somehow
[20:33:04] <ali1234> yes. have you ever tried actually clicking on one of the lines to get to that line?
[20:33:11] <altendky> and they don't group the lines in groups of 64
[20:33:13] <ali1234> it's near impossible because they are 1 pixel
[20:33:21] <altendky> sure
[20:33:27] <altendky> i never suggested you make an unusable thing
[20:33:33] <ali1234> if they *did* group them by 64 lines, then they would be bigger
[20:33:36] <altendky> i rather suggested you make it more usable
[20:33:41] <ali1234> you could click on the one you wanted to click on
[20:33:44] <altendky> by making that highlighting size independent
[20:33:51] <altendky> nope
[20:33:59] <altendky> that only works well for a single size of file
[20:34:10] <ali1234> so what you have to do instead of click near what you want, and then scroll up and down in the file looking for the error
[20:34:14] <altendky> the height of the bar need not relate in any way to the number of lines in the file
[20:34:25] <altendky> especially when you have one thing, yellow, that should win
[20:34:34] <ali1234> this is really annoying because when you are scrolling you have to track with the scroll, then start parsing again
[20:34:42] <ali1234> following that up down movement is really difficult for me
[20:34:44] <altendky> the only error you are describing is their choice to make the bar 1 pixel high rather than five etc
[20:34:54] <altendky> but that has nothing to do with the number of lines in the file
[20:35:29] <altendky> it has only to do with how you choose to render your information
[20:35:29] <ali1234> i think it does
[20:35:32] <altendky> it doesn't
[20:35:45] <altendky> but i guess i have to go copy paste a bunch to show it
[20:36:30] <ali1234> none of this is helping me actually implement it :)
[20:36:40] <altendky> https://usercontent.irccloud-cdn.com
[20:36:41] <ali1234> i mean the design could change part way through
[20:36:49] <altendky> https://usercontent.irccloud-cdn.com
[20:37:19] <ali1234> yeah. it's all squashed, so how do you get to what you want?
[20:37:26] <altendky> yes, you not understanding that the size of presentation of a marker does not have to relate to arbitrary grouping of data is a hinderance
[20:37:30] <altendky> huh?
[20:37:37] <altendky> the bar is not 20 times shorter
[20:37:44] <altendky> it's the same size even with 20x the line count
[20:37:59] <altendky> sure, it's too short probably because it's hard to hover and click
[20:38:03] <ali1234> see what i want to do is put the scroll bar on the scroll bar, and then paginate the code into pages of 64 lines
[20:38:11] <altendky> but that's just a decision they made that has nothing to do with the line count
[20:38:17] <altendky> because they don't control the line count
[20:38:20] <ali1234> then you never need to look at vertically scrolling text
[20:38:31] <altendky> yes, i understand you want arbitrary boundaries
[20:38:53] <ali1234> that way the things you actually click on are guaranteed to never ever been smaller than some minimum size
[20:39:03] <altendky> and you are going to design something around your monitor and your resolution and your window size and your display scaling
[20:39:09] <altendky> they aren't
[20:39:26] <ali1234> a 1080p monitor is not really uncommon these days
[20:39:26] <altendky> because i'll go buy an 8k display and run it at 100% and so on
[20:39:52] <altendky> and your pixels will be way smaller for me than for you
[20:39:53] <ali1234> just run it in 2x mode
[20:39:58] <altendky> and your whole system will be designed around that
[20:40:01] <altendky> ugh...
[20:40:08] <altendky> that's a rude and disgusting approach
[20:40:19] <altendky> and points out exactly how your approach is making bad assumptions
[20:40:25] <altendky> and you are designing your whole system around that
[20:40:27] <ali1234> okay then i'll make it in pts. it will still have groups of 64 though
[20:41:31] <ali1234> you realise this is software that only i and maybe 4 other people will ever use right?
[20:42:26] <altendky> you realise that you don't understand, right? but sure, assuming resolutions and groupings and so on will probably be 'easier'. you seem to be investing sufficient time in this to not play the 'this is just a quick little thing who cares' card though
[20:43:29] <ali1234> resolution-independant toolkits will be great when you can geta 24" monitor with the pixel density of an iphone display
[20:43:47] <altendky> not sure the point there
[20:44:21] <altendky> i'm not saying you can't draw based on pixels so you get sharp lines. i'm saying you can't exclusively think about them and design your whole system of groupings around the pixel count on your display
[20:44:41] <ali1234> okay, but it doesn't actually change anything
[20:44:55] <altendky> yes, you will still not get what i'm suggesting. have at
[20:45:42] <ali1234> i mean, the main point is that scrolling through lines of samples is not feasible, because they all look the same (and you want to group them by similarity)
[20:46:00] <ali1234> so it is better to arbitrarily group them in a way that avoids scrolling
[20:46:10] <altendky> you still don't get it. but what is it you wanted help with? this seems pretty much not a big deal given what you've already done
[20:46:16] <altendky> it isn't but hey
[20:46:23] <ali1234> by contrast, the timeline display does not look all the same... it is colour coded
[20:47:02] <ali1234> i want to know the easiest way to make a scrolling timeline widget... either your design or my design, it does not really matter, the basics will be pretty much the same
[20:47:15] <ali1234> place blocks, click on them... there will be a very large number of blocks either way
[20:47:27] <altendky> isn't it just 'draw all this stuff and handle a click event'?
[20:47:31] <ali1234> yes
[20:47:43] <altendky> i don't see the difficulty given the other things you've already done
[20:47:52] <altendky> it seems fairly similar
[20:47:56] <ali1234> so your recommendation is to handle all painting and coordinate transforms myself?
[20:48:04] <ali1234> there's nothing better than that?
[20:48:09] <altendky> i thought your design was to avoid transforms
[20:48:19] <ali1234> no, my design is to avoid scrolling in the other view
[20:48:20] <altendky> for grouping to 64 and giving each on x pixels
[20:48:30] <altendky> *each one x pixels
[20:48:36] <ali1234> the timeline view, the one with the blocks, has horizontal scrolling
[20:49:00] <ali1234> the line view has no scrolling and does not need to handle clicks
[20:49:02] <altendky> drop your widget you draw on in a scroll area?
[20:49:21] <altendky> if you want a regular scroll bar for it
[20:49:35] <ali1234> a regular scroll bar should be okay
[20:49:58] <altendky> or just have a stand alone scroll bar and when it moves repaint the other widget
[20:50:00] <altendky> either way
[20:50:05] <ali1234> it should not be more than 25x the width of the window
[20:50:37] <altendky> that should result in a navigable scrolling experience
[20:50:47] <altendky> (unlike some code files i've dealt with)
[20:51:12] <altendky> you start hitting 10k lines and the scrollbar isn't very useful anymore, just jumps too far
[20:51:32] <altendky> let alone my present 100k+ line generated files :|
[20:51:59] <ali1234> it should also support keyboard nav, and jump to selection
[20:52:17] <altendky> key event or shortcuts or whatever
[20:52:41] <ali1234> i mean i could do it with a gridview, but i dont know how well that will perform... probably not very well
[20:53:03] <altendky> i would just paint it i would think
[20:53:18] <altendky> i mean it just doesn't strike me as that different in this aspect than what you shared links to
[20:53:22] <altendky> i get it's different data
[20:53:26] <altendky> a different presentation
[20:53:38] <altendky> but it's still just some stuff being drawn somehow
[20:53:51] <ali1234> the stuff i shared has no navigation at all... it only has "play" and "pause"
[20:53:59] <altendky> that doesn't particularly matter
[20:54:04] <ali1234> and it is written in opengl
[20:54:33] <altendky> have you written a paint method?
[20:54:37] <ali1234> no
[20:54:49] <ali1234> i've written a GLUT render method
[20:55:07] <altendky> i mean you could presumably do it the same as you what you shared
[20:55:14] <altendky> not sure why that was gl but...
[20:55:25] <altendky> if it makes sense there it seems like it would make as much sense here?
[20:55:31] <ali1234> because i know GL, i don't know Qt anywhere near as well
[20:55:58] <altendky> how about this, i'm not sure why they should be different than each other.
[20:56:00] <ali1234> but the thing about GL is you have to implement scrollbars yourself, by hand, also picking, coordinate transformation, highlighting the selection
[20:56:20] <altendky> you could put a qt scroll bar next to your gl...
[20:56:23] <ali1234> in Qt you just make an object and say it should have a border this colour and you are done
[20:56:29] <altendky> well
[20:56:32] <altendky> for widgets sure
[20:56:48] <ali1234> exactly, so this is why i would rather not do all the painting myself
[20:56:52] <altendky> and maybe for items in graphics views or whatever Avaris mentioned
[20:57:02] <altendky> but when you are making a million of them...
[20:57:07] <ali1234> right
[20:57:07] <altendky> you don't want widgets
[20:57:12] <ali1234> so i need a happy medium
[20:57:23] <altendky> maybe graphics view. maybe just a paint event
[20:57:26] <ali1234> i think GraphicsScene is much lighter than full widgets
[20:57:56] <ali1234> maybe i do the whole thingin QML
[20:58:07] <ali1234> make a model for the timeline and just have a flickable
[20:58:10] <altendky> that seems vaguely orthogonal
[20:58:34] <ali1234> then i'm back to the python/QML boundry stuff from before, but at least that's a know problem :)
[20:58:38] <altendky> you aren't going to create a separate whatever-qml-calls-their-widgets for each of the million things
[20:58:54] <altendky> at least i would think that would still not be a good idea
[20:58:59] <ali1234> no, flickable doesn't (delegates) they are made on the fly when they become visible
[20:59:21] <ali1234> there is a cache too to make it fast
[20:59:40] <ali1234> maybe i just embed a QML widget for the timeline and figure out how to get clicks back to the python side
[20:59:45] <altendky> even just what you see on screen is still a lot
[20:59:56] <ali1234> not really... QML is really fast
[21:00:09] <ali1234> it's so much faster than widgets
[21:00:21] <ali1234> when you use a proper model, anyway
[21:00:26] <altendky> 40k or whatever is still a lot
[21:00:30] <ali1234> 40k??
[21:00:36] <altendky> 10k?
[21:00:44] <altendky> how many 'boxes'?
[21:01:05] <altendky> divide that by the 25 you said about the scroll bar
[21:01:05] <ali1234> 10k max, probably fewer... like you said 5x5 is quite small
[21:01:09] <altendky> that's how many are on screen at once
[21:01:23] <ali1234> 32 vertical * however many fit horizontally
[21:02:06] <altendky> at 10 pixels by 32 of them by 4000 pixel display you are at 13k on screen at a time
[21:02:32] <ali1234> if you have a 4000 pixel display you should be running it at 2x, or maybe you are lucky and i used pts
[21:02:40] <altendky> stop telling people to run it at 2x
[21:02:43] <altendky> that's silly
[21:02:49] <ali1234> it really isn't tho
[21:02:51] <altendky> anyways, 6500
[21:02:54] <altendky> it is'
[21:03:17] <ali1234> on a 4000 pixel display, the boxes should be like 20px
[21:03:26] <altendky> why?
[21:03:27] <ali1234> on 1920 they should probably be about 10ps
[21:03:30] <altendky> i run at 100% on a 32"
[21:03:36] <ali1234> because otherwise it will be impossible to click on them accurately
[21:03:37] <altendky> you keep leaving out variables
[21:03:44] <ali1234> they should be easy to click on
[21:03:47] <altendky> being very you-centric
[21:03:55] <altendky> and your setup
[21:03:56] <ali1234> cos... i'm the main user :)
[21:04:16] <altendky> beware when you buy a new computer. :|
[21:04:27] <altendky> all your stuff will look like garbage because you will run it at 2x
[21:04:32] <ali1234> i won't be buying a 4k monitor an time soon
[21:04:34] <Avaris> just have a configuration for the box size in pixels, and everybody is happy :)
[21:04:39] <ali1234> right ^
[21:04:53] <altendky> and don't design your entire system around it being 64 frames per etc etc
[21:04:54] <ali1234> xfce doesnt support 4k at all. i think there is a 2x mode but maybe not even that
[21:04:58] <altendky> because things vary
[21:05:12] <altendky> i doubt xfce can't run on a 4k monitor
[21:05:19] <altendky> again, you are leaving things out
[21:05:21] <ali1234> it can, its just that everything is tiny
[21:05:22] <altendky> 4k isn't scaling or high dpi
[21:05:26] <altendky> it's just a pixel count
[21:05:36] <ali1234> unless you have a 42" 4k monitor
[21:05:42] <altendky> if you double the resolution and the monitor size then it's all the same size...
[21:05:44] <ali1234> then its fine
[21:05:59] <altendky> 13" to 28" are pretty common place
[21:06:08] <altendky> all available in fhd through 4k
[21:06:32] <ali1234> yeah, and it is a huge pita when you try to render a truetype font without cracks between glyphs...
[21:06:50] <ali1234> even if you specify all sizes in pixels and turn off antialiasing
[21:07:01] <ali1234> everyone assumes that everything has to be resolution independant
[21:07:12] <altendky> i didn't
[21:07:30] <altendky> i'm rather trying to talk about being able to handle things well. not 'be unaware and render stupidly'
[21:07:51] <altendky> i never suggested smudges etc
[21:07:52] <ali1234> well you didn't write freetype then :)
[21:08:13] <altendky> i think fonts are a different game
[21:08:20] <ali1234> it's all related
[21:08:26] <altendky> they aren't exactly intended to be pixel perfect etc etc
[21:08:36] <ali1234> i dont see why we cant have both
[21:08:37] <altendky> they are intended to look like the designed letters
[21:08:41] <ali1234> but apparently we cant
[21:09:00] <altendky> luckily you aren't trying to deal with this now
[21:09:15] <ali1234> true
[21:09:38] <ali1234> so anyway... the point is, however big your monitor is... the timeline is going to have max 5000 rectangles in it
[21:11:01] <ali1234> 32* 125 = 4000
[21:11:29] <ali1234> that will make the total scrolling are 25x the visible area
[21:11:48] <ali1234> that seems fairly reasonable
[21:20:23] -!- kushal has quit [Ping timeout: 240 seconds]
[21:20:39] -!- kushal has joined #pyqt
[21:31:07] -!- BPL has quit [Quit: Leaving]
[21:39:05] -!- honigkuchen has quit [Remote host closed the connection]
[21:42:50] -!- TechSmurf has quit [Remote host closed the connection]
[21:46:25] -!- honigkuchen has joined #pyqt
[21:56:29] <ali1234> okay i made a listview with 4000 items, each delegate has 32 rectangles... it performs fine
[21:58:19] -!- TechSmurf has joined #pyqt
[23:06:29] -!- Belxjander has quit [Quit: AmigaOSv4.1.6+//PowerPC native]
[23:10:33] -!- Belxjander has joined #pyqt