| | <<<Back 1 day (to 2018/03/08) | 20180309 |
| sebras | tor8: I just compiled tor/ui and it looks just like windows 3.11 :) | 12:37.20 |
| | tor8: apart from the icons of course. | 12:37.28 |
| | tor8: and the stipple pattern as background in scrollbars and the top/bottom arrowes. | 12:37.49 |
| | tor8: when the window is resized to small the components are drawn on top of each other though. | 12:38.15 |
| | tor8: seems like creating a ink/freetext widget works well as well. | 12:40.36 |
| tor8 | sebras: windows 95, not 3.1... | 12:44.30 |
| sebras | tor8: how do you feel about the top two patches of sebras/master? | 14:35.42 |
| | tor8: oh, yes, 95. | 14:56.38 |
| | tor8: btw, sebras/master clusters well. | 14:56.46 |
| tor8 | sebras: does the cluster test various encryption and passwords? | 15:10.17 |
| sebras | I wouldn't expect so. | 15:13.13 |
| | tor8: the calls to glEnd() in ui_end_text() and lookup_glyph() returns GL_INVALID_OPERATION. | 15:19.21 |
| tor8 | sebras: odd. is your window so small you get overlaps? | 15:20.03 |
| | I've seen GL_INVALID_OPERATION when drawing rectangles that are negative | 15:20.20 |
| | sebras: sebras/master LGTM | 15:26.00 |
| sebras | tor8: if I resize the window I get overlaps. | 15:35.32 |
| tor8 | sebras: yes. that's only to be expected (don't do that!) | 15:35.57 |
| | I haven't limited the window size | 15:36.07 |
| sebras | tor8: I wanted to locate the GL_INVALID_OPERATION that you mentioned so i added checks after every gl-call. the two plaaces I mentioned above returns GL_INVALID_OPERATION consistently. | 15:36.45 |
| | tor8: another option would be to restrict widgets from overlaping. | 15:37.16 |
| tor8 | do you always get it, or just when resizing so the annotation panel extends beyond the left edge of the screen? | 15:37.21 |
| sebras | tor8: the GL_INVALID_OPERATION? | 15:37.39 |
| tor8 | yes. | 15:37.43 |
| sebras | tor8: always, immedately opening. | 15:37.53 |
| | immediately after opening. | 15:37.58 |
| | several times. | 15:38.01 |
| tor8 | strange. I have never seen that one. | 15:38.14 |
| | I get it if I let the annotation panel extend beyond the left edge of the window | 15:38.32 |
| sebras | tor8: you never explicitly check glGetError() after every glEnd() call. | 15:38.42 |
| tor8 | glGetError can be delayed, depending on how much processing the opengl driver does | 15:39.15 |
| | so an error may not occur until much later | 15:39.21 |
| sebras | tor8: I added calls to glGetError() after _every_ glXyzxyz() call. | 15:39.22 |
| tor8 | oh, my case may be because it won't let the glScissor extend past the window (and I scissor the list region for scrolling) | 15:39.43 |
| | sebras: the only thing I call between glBegin(GL_QUADS) in ui_begin_text and the glEnd in ui_end_text/lookup_glyph is glTexCoord2f and glVertex2f | 15:42.17 |
| | try commenting out the ui_draw_string function body, and see if you still get the error | 15:42.58 |
| | and do you get the same errors with the master branch? | 15:43.36 |
| | I haven't changed the text drawing | 15:43.45 |
| sebras | tor8: first glBegin() is valled in ui_begin_text() due to ui_draw_string() then glBegin() is called in lookup_glyph() multiple times, lastly glEnd() is called in ui_end_text(). I think the call to glBegin() in lookup_glyph() is the one creating the problems. | 15:50.23 |
| | but I freely admit that I don't understand this yet. | 15:51.13 |
| | commeting out the function body in ui_draw_string() still reports error, bug _much_ fewer. | 15:52.10 |
| malc_ | sebras: https://github.com/apitrace/apitrace | 15:55.15 |
| sebras | tor8: after instrumenting origin/master I can report that I see GL_INVALID_OPERATION after glEnd(0 in ui_draw_image() there too. | 16:01.42 |
| | tor8: but only once. | 16:01.49 |
| | tor8: is this because you are nesting calls to glBegin()/glEnd()? | 16:02.03 |
| tor8 | sebras: I should not be nesting calls! where do you see that? | 16:02.31 |
| sebras | tor8: _INVALID_OPERATION is generated if glBegin is executed between a | 16:02.50 |
| | glBegin | 16:02.50 |
| | and the corresponding execution of glEnd. | 16:02.52 |
| | according to https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glBegin.xml | 16:02.58 |
| tor8 | sebras: lookup_glyph calls glEnd() at the top | 16:03.01 |
| sebras | granted it is an old version. | 16:03.05 |
| tor8 | if it cannot find a cached glyph in lookup_glyph, I call glEnd(), render the glyph and update the texture, then start with a new glBegin() | 16:03.41 |
| sebras | tor8: that makes sense, but I think you cannot call lookup_glyph() from a function that encloses lookup_glyph() within glBegin()/glEnd(). | 16:04.43 |
| tor8 | ui_begin_text calls glBegin, then somewhere inside that it may call lookup_glyph that calls glEnd and glBegin and then ui_end_text calls glEnd | 16:05.34 |
| | they are not nested. | 16:05.37 |
| sebras | tor8: ah, ah, ah. yes. | 16:06.00 |
| | tor8: on origin/master if I comment out the body in ui_draw_image() I no longer get the errors. | 16:10.24 |
| | tor8: just commenting out glBegin(GL_TRinAGLE_STRIP) to glEnd() in ui_draw_image() also causes the errors to disappear. | 16:11.17 |
| | of course I only get a gray window though. | 16:11.34 |
| | if I just introduce the calls to glBegin() and glEnd() without the contents inbetween glEnd() also seems to indicate error. | 16:12.39 |
| tor8 | sebras: try disabling the other functions (like glBlendFunc or glEnable(GL_BLEND)) | 16:13.01 |
| | this is going to be impossible for me to debug, without having the same graphics driver and version | 16:13.43 |
| sebras | tor8: I realize that. | 16:14.14 |
| tor8 | sebras: how far back can you reproduce the error? | 16:17.12 |
| sebras | tor8: back in git history? | 16:17.32 |
| tor8 | yes. | 16:18.40 |
| | sebras: what's the output ofr "glxinfo | grep KHR" for you? do you have the GL_KHR_debug extensionL | 16:18.59 |
| sebras | tor8: yes | 16:19.43 |
| | https://pastebin.com/raw/sPzqX3LU | 16:19.47 |
| tor8 | sebras: try the tip of tor/ui now | 16:29.39 |
| | there's a temporary fix to enable more detailed debugging | 16:29.47 |
| sebras | tor8: 2 min. | 16:30.05 |
| | tor8: I see an error after glEnd() in draw_image() in commit 83a00b0a38558e3e64f38d8a584808e323f4d706 | 16:31.41 |
| | tor8: that's some time back at least. | 16:32.09 |
| tor8 | so it's nothing recent I've broken at least | 16:32.30 |
| sebras | tor8: doesn't seem like it. | 16:32.41 |
| | tor8: I pulled in my error reporting patch too: https://pastebin.com/raw/8FvP0uBg | 16:34.29 |
| | this is on top of you updated tor/ui | 16:34.39 |
| tor8 | hm. sounds like your driver doesn't support something I expect to be there. | 16:35.32 |
| sebras | related to GL_TRIANGLE_STRIP..? | 16:35.50 |
| tor8 | GL_ARB_texture_non_power_of_two? | 16:35.51 |
| | probably related to texture drawing, since that's what's used to draw text and images | 16:36.09 |
| sebras | glxinfo lists GL_ARB_texture_non_power_of_two | 16:36.25 |
| tor8 | but you see text and images? | 16:36.27 |
| | disable text, and try tweaking the calls in ui_texture_from_pixmap | 16:36.55 |
| | hardcode has_ARB_texture_non_power_of_two to 0 and see if that helps | 16:37.10 |
| sebras | tor8: text and images? yes, the UI seems to work fine. and the PDF texture is rendered. | 16:38.18 |
| tor8 | so I wonder jsutt which extension/deprecated function it's complaining about | 16:38.39 |
| sebras | tor8: hardcodeing has_ARB_texture_non_power_of_two to 0 has no effect. | 16:40.21 |
| | tor8: what do you mean by "disable text"? | 16:40.40 |
| tor8 | yeah. I wouldn't expect that to make much difference, if you can see stuff drawn | 16:40.51 |
| | all text is drawn via ui_draw_string | 16:41.09 |
| | so if you kill that function, you should be able to see whether it's the page drawing or text drawing that's causing trouble | 16:41.27 |
| sebras | tor8: commenting out hte contents of ui_draw_string() and having it return 0 still has the error. | 16:43.04 |
| | tor8: commenting out the block of gl-calls between glBegin() and glend() in ui_draw_image() removes most of the deprecation warnings. only a single one remains. | 16:44.25 |
| | also commenting out the glBegin()/glEnd() calls themselves _completely_ removes _all_ deprecation warnings. | 16:45.14 |
| malc_ | sebras: what about LIBGL_ALWAYS_SOFTWARE=1 build/xx/mupdf-gl ... ? | 16:45.26 |
| sebras | malc_: if I still keep the calls to glBegin()/glEnd() and what's inbetween them in ui_draw_image() but I set LIBGL_ALWAYS_SOFTWARE=1 I still get deprecation warnings and an errlr. | 16:46.53 |
| | to me this appears to be related to GL_TRINAGLE_STRIP somehow. | 16:47.12 |
| malc_ | sebras: which means that tor _CAN_ reproduce it.. or at least should be able to | 16:47.39 |
| sebras | malc_: given that some interesting library actually cares about LIBGL_ALWAYS_SOFTWARE and does something sensible. | 16:48.34 |
| malc_ | sebras: yes.. that assumes he uses mesa | 16:49.12 |
| tor8 | sebras: not surprising, since without the glbegin/glend calls no drawing operations are actually invoked taht could trigger the errors | 16:49.19 |
| sebras | tor8: true. but at least it is localized to _those_ calls now. | 16:49.51 |
| | tor8: that means that if it is an unsupported extension or deprecated function it must be one of those. | 16:50.16 |
| tor8 | yeah, but that's just knowing when the symptoms appear. the actual calls that cause the errors could be anywhere else. | 16:50.25 |
| sebras | but it is not the clals glBlendFunc(), glEnable(), glBindTexture(), glDisable() in ui_draw_image(). those functions are fine to call. | 16:50.43 |
| tor8 | because opengl is just a big fat state machine, that doesn't necessarily validate its state until it gets used | 16:50.44 |
| | so it might be glBlendFunc, we just can't know until we try to use the state it set | 16:51.05 |
| sebras | oh. | 16:51.15 |
| | ok. | 16:51.17 |
| tor8 | which is why 3d programming is so "hard" | 16:51.27 |
| | because debugging it is nearly impossible | 16:51.32 |
| | you'll have to try disabling each function one function at a time and see when things actually improve | 16:52.03 |
| | it's *probably* related to textures and the texture drawing, since the errors pop up when you draw something with a texture | 16:52.28 |
| sebras | tor8: are textures used when you draw the file picker? | 16:53.13 |
| tor8 | yes. | 16:53.38 |
| | the file picker draws text. ergo textures. | 16:53.45 |
| | sebras: I'm installing an ubuntu in virtualbox, which should let me use software opengl to see if I can replicate your errors | 17:01.16 |
| | my system has the nvidia drivers | 17:01.23 |
| | and I'm *not* messing about with those.... | 17:01.29 |
| sebras | OpenGL vendor string: Intel Open Source Technology Center | 17:01.55 |
| tor8 | sebras: do you get that with LIBGL_ALWAYS_SOFTWARE=1 too? | 17:02.19 |
| sebras | tor8: wait... | 17:03.10 |
| | server glx vendor string: SGI | 17:03.21 |
| | client glx vendor string: Mesa Project and SGI | 17:03.22 |
| | OpenGL vendor string: Intel Open Source Technology Center | 17:03.22 |
| | how do I know which one is used? | 17:03.30 |
| tor8 | glx is irrelevant (it's just how it coordinates with the X server) | 17:05.08 |
| sebras | I get OpenGL vendor string: VMware, Inc. if I set LIBGL_ALWAYS_SOFTWARE=1 | 17:06.25 |
| | tor8: take a look at the two top patchs of sebras/ui | 17:24.30 |
| | tor8: the top one no longer prints any deprecation warnigs, but the next one down does. | 17:24.50 |
| | the interesting thing is that there are only four gl calls in the one that fails: glBegin, glend, glEnable and glDebugMessageCallback | 17:25.31 |
| tor8 | sebras: did you push? | 17:26.16 |
| sebras | tor8: I did. | 17:26.36 |
| | tor8: ehm... git push -f sebras HEAD:refs/master/ui | 17:26.56 |
| | tor8: I pushed something new. | 17:27.04 |
| | tor8: it is about 1:30am here, so I'm not at my smartest. | 17:27.25 |
| tor8 | sebras: maybe the intel driver doesn't like texture subimage updates? | 17:27.59 |
| | let's continue this next week then. enjoy your weekend! | 17:28.42 |
| sebras | tor8: how would it know that we want this | 17:28.49 |
| | tor8: given that I commented out virtually all GL-calls..? | 17:29.10 |
| tor8 | ohhh. | 17:29.39 |
| | is it that bad that it doesn't like GL_QUADS? | 17:29.47 |
| sebras | perhaps..? | 17:29.55 |
| tor8 | GL_QUADS are deprecated/not-supported in modern OpenGL | 17:30.13 |
| | but we're not using modern opengl, we're using stone age opengl | 17:30.39 |
| | most of them could be redone with GL_TRIANGLE_STRIP (just changing the order of the vertices | 17:31.22 |
| sebras | tor8: is it easy enough for you to make a patch for this? | 17:33.37 |
| | tor8: or do you prefer to wait? | 17:33.49 |
| tor8 | sebras: try tor/ui now | 17:35.05 |
| sebras | tor8: same. see sebras/ui-still-with-errors to see what I did. | 17:41.45 |
| | tor8: plain tor/ui prints no deprecation warnings though! | 17:42.43 |
| | tor8: I'm confused. | 17:42.55 |
| tor8 | you're not supposed to call glGetError inside a glBegin/glEnd | 17:43.11 |
| | it's very limited in what it allows inside those | 17:43.20 |
| sebras | tor8: oh, so I created all this problem myself. | 17:43.32 |
| | :-) | 17:43.39 |
| tor8 | possibly. I wouldn't bet 100% on it. | 17:43.52 |
| | but try removing the checks inside the glBegin/End and see if you still see warnings? | 17:44.09 |
| sebras | tor8: I wentback and compiled plain 8d251cbe0 | 17:45.43 |
| | tor8: resizing the file picker there generates gl debug: GL_INVALID_VALUE in glScissor when the right hand scrollbar overlaps with the cancel button down to the left. | 17:46.17 |
| | tor8 so a similar situation as you saw with the annoation panel. | 17:46.29 |
| | no deprecation warnings. | 17:46.50 |
| | tor8: and yes, if I remove the glGetError() calls between glBegin() and glEnd() it no longer complains about deprecated functions. | 17:51.07 |
| tor8 | nice. | 17:52.18 |
| | good to know it was the quads causing you warnings. | 17:52.24 |
| | those are easy enough to avoid | 17:52.30 |
| sebras | tor8: it was not. | 17:52.58 |
| | tor8: it was my calls to glGetError() cat caused the deprecation warnings. | 17:53.24 |
| | tor8: the gl debug: GL_INVALID_VALUE in glScissor I see now is when the scissor width in ui_list_begin() becomesnegative. | 17:54.34 |
| | tor8: when I resize the file picker. | 17:56.44 |
| | tor8: similarly the x-position becomes negative if the annoation panel is open and you resize. | 17:57.21 |
| | these where the original errors that I wanted to track down. :) | 17:57.40 |
| | tor8: ok. so i think I'll go to bed now. | 18:01.38 |
| | tor8: btw, all the oss-fuz bugs were closed by oss-fuzz today. that just seems plain wrong. | 18:02.03 |
| | I think it just is unable to reproduce at the moment. | 18:02.18 |
| | tor8: zzz. | 18:02.49 |
| | Forward 1 day (to 2018/03/10)>>> | |
Log of #mupdf at irc.freenode.net.