<wpwrak>
all this debug output looks as if it should be useful to figuring out why my redirected TW disappears, too. and easier to use than an event handler override ;-)
<wpwrak>
now what version would that be ... guess > 3.20 :-(
<whitequark>
wpwrak: you can work around that
<whitequark>
well...
<wpwrak>
bump some refcount, i guess ? with something like #if GTKMM_VERSION_MINOR < 20
<wpwrak>
makes opengl context creation work for GW, but with a quirk: the screen comes up with a white background, and only turns black when something happens
<wpwrak>
also, TW still fails
<whitequark>
yeah I didn't patch that
<wpwrak>
"happens" = e.g., hover over axis or icon
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer06 has joined #qi-hardware
DocScrutinizer06 is now known as DocScrutinizer05
<wpwrak>
of those, initrd was probably the best. proper innovation, the stuff patents should be made of.
<whitequark>
lol
<wpwrak>
and it also solved a rather nasty situation that began to build up at that time: distributions needed more and more different boot floppies, to avoid driver X from irreparably (well, until reset) trashing registers hardware Y. the joy of ISA. we already had modules, but no way to control at boot time which to load.
<wpwrak>
whitequark: applied sumaxofogi on top of voqacunuyo and afiqahekeb
<wpwrak>
GW now comes up cleanly (i.e., black background). TW still fails to bring up opengl
<wpwrak>
lemme see if this goes away if i pick up the latest changes from git ...
<wpwrak>
seems that they added some python antidote ;-)
<wpwrak>
master @ 5c34b3f6ef86b94b9360023ddb5c6a35f935ade6 + sumaxofogi: GW and TW come up, background is black. however ... GW doesn't show the dashed lines until ther is some "action". also, slvs prints 2 x "glGetError() == 0x501"
<whitequark>
bleh
<whitequark>
what does MESA_DEBUG LIBGL_DEBUG bring out?
<wpwrak>
now all looks good: GW and TW come up, background color is right, update happens in time, no complaints on the console.
<wpwrak>
line drawing is still as glacially slow as before. but i guess that's unrelated.
<whitequark>
wait, really?
<whitequark>
that... makes no sense
<wpwrak>
did that ever stop computers from misbehaving ? :)
<whitequark>
wpwrak: pushed that to master
<whitequark>
wpwrak: can you do: cmake . -DOPENGL=1 and rebuild?
<whitequark>
wpwrak: nevermind, that's not actually possible to do on GTK3.
* whitequark
stares
<whitequark>
wpwrak: are you *absolutely sure* your X server / graphics driver combo isn't totally fucked up?
<wpwrak>
built master ... works (just with the slowness)
<whitequark>
can you show me GDK_DEBUG=ALL output and drag something a bit
<whitequark>
on my machine, dragging a line in solvespace eats about 25% of a core plus 10% for xorg
<whitequark>
and it's incredibly snappy
<wpwrak>
x server is generally a bit sluggish, because if memory is always runnings low and there's a background load of junk in browser tabs, but nothing that would explain lines being so slow
<whitequark>
what does the fps counter say?
<whitequark>
again on my machine with intel graphics it takes 1ms to draw a frame
<whitequark>
even with DocScrutinizer05's 1200ppi mouse it would probably not have much difference coping with the load!
<wpwrak>
ah yes, that has gotten faster. could be because i killed the background activities.
<whitequark>
ok so it has nothing to do with vsync
<whitequark>
or glFlush
<wpwrak>
ulimit so far hasn't caused any trouble. been running it for a couple of minutes, moving the mouse around
<wpwrak>
what's also fun is that, when moving the mouse slowly over the horizontal/vertical position, the H/V appears and follows the mouse, while the line remains frozen
<whitequark>
that one I know of...
<wpwrak>
i'll go for a nap. no new bugs or nagging about features for a while ;)
<wpwrak>
one thing i noticed is that it seems that the window gets mapped before receiving its position, i.e., it / its frame very briefly appears at a different position, then the window is drawn at the final position. not sure who does what in that sequence.
<whitequark>
wpwrak: that's "normal"
<wpwrak>
perfect then ;-)
<whitequark>
it's slightly inelegant but really not worth fixing
<whitequark>
maybe once I rewrite all of the platform code to be sane
<wpwrak>
yeah, doesn't cause problems
<whitequark>
patch looks better now
<whitequark>
well, I'm not happy with how it's structured and formatted but at least the semantics makes sense
<whitequark>
will apply in a few hours
<wpwrak>
thanks !
sandeepkr__ has joined #qi-hardware
sandeepkr_ has quit [Read error: Connection reset by peer]
sandeepkr_ has joined #qi-hardware
sandeepkr__ has quit [Ping timeout: 260 seconds]
<DocScrutinizer05>
((very briefly appears at a different position)) dosn't cause problems as long as no stupid windows desktop re-arranges all icons on screen permanently, like it's done when you switch to a different display resolution
<DocScrutinizer05>
...on windoze
<DocScrutinizer05>
same effect happens as well when windows reloads display driver, on NVidia updating the graca driver crap
<DocScrutinizer05>
0,3s black, then deskzop comes back re-arranged
<DocScrutinizer05>
desktop*
pcercuei has joined #qi-hardware
<DocScrutinizer05>
rather boring video of "interesting snowflakes" http://maemo.cloud-7.de/share-service/DSCF2275.MOV - what's *really* highly interesting is the shake stabilizer of that Fuji camera, conider I took that video one_handed and the original shaking was X and Y just as bad as in Z-rotation, but the stabilizer totally removed it, except the latter
<strawberyargon>
i feel "yea its good" didnt do it justice, its most acceptable to the point i dont think about shakyness. so my focus then went to the next thing, which was compression
<DocScrutinizer05>
well, 5D mk-II (or III) yeah, I wish I could at least remote trigger this Fuji XQ1, but then it's a completely different class than Canon 5D and alas no magic lantern or _anything_ available
<DocScrutinizer05>
a 5D would be overkill for my purposes
<DocScrutinizer05>
but something with at least 100mm (better 150), focus distance <40cm, magnif >= 1.0 would be much appreciated
<DocScrutinizer05>
and I actually started looking for cameras that allow hacked firmware and have a decent versatile hacked firmware
<DocScrutinizer05>
a used 5D-Mk1 with primary 100mm macro might match all my criteria
pcercuei has quit [Quit: leaving]
<DocScrutinizer05>
then OTOH a DL24-500 (with magn=4) is a nice telescope too ;-) I just wonder if the macro properties it has are any good, also if it ever might see hacked firmware
<DocScrutinizer05>
>> Magnification Up to 4 x (angle of view equivalent to that of approx. 2000 mm lens in 35 mm [135] format)<<
<DocScrutinizer05>
>>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) <<
<DocScrutinizer05>
not quite sure if the latter really means I could do decent macro shots of areas 10*10mm, with lens min 30cm from object
<DocScrutinizer05>
if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification
<DocScrutinizer05>
but too much guessing from my side in all that
<wpwrak>
canon powershot powershow sd880is aka ixus 870 is goes down to 20 mm and runs chdk. and you've already seen many pictures taken by it ;-)
<DocScrutinizer05>
ooh, that 4 times magnification is digital, meh
<DocScrutinizer05>
I don't want "to go down to..." - I need a certain minimum distance of 30cm from lens to object ;-)
<wpwrak>
at 20 mm, your main problem is to get light to the object, because the lens tends to shadow it pretty well, especially if you don't have a lot of ambient light.
<wpwrak>
that nikon has a nice exposure range. the sd880is only goes -3/+3 EV, which can sometimes be insufficient.
<DocScrutinizer05>
with DL24-500 in tele mode, minimum distance is 70cm which is maybe a tiny bit clumsy since I need to stand up to reach the camera, but as long as it makes crisp pictures (actually video, via HDMI-out) of an area as 'large' as 10*10mm
<wpwrak>
naw, for getting close, you want macro mode.
<wpwrak>
tele may sound useful, but it isn't :)
<DocScrutinizer05>
I have three requirements: format filling 10*10mm macros, video to large monitor, *minimum* 30cm distance object<->lens
<DocScrutinizer05>
if the thing can serve "dual-use" as mice "telescope" too, I won't complain
<DocScrutinizer05>
nice*
<wpwrak>
30 cm or mm ?
<DocScrutinizer05>
2000mm effective lens sounds like the latter is granted
<DocScrutinizer05>
CENTImeter
<DocScrutinizer05>
300mm
<wpwrak>
you want a 10x10 mm field from 30 cm ?
<DocScrutinizer05>
yes
<wpwrak>
i hope you're good at grinding your own lenses ;-)
<DocScrutinizer05>
why?
<wpwrak>
i doubt anything even remotely like this is commercially available
<DocScrutinizer05>
err
<DocScrutinizer05>
aiui a 150mm lens has object size == picture_on_sensor size when object has 150mm distance from sensor
<DocScrutinizer05>
aka "magnicication = 1.0"
<DocScrutinizer05>
if it could get focused to 15cm distance
<wpwrak>
yes, that's the problem
<DocScrutinizer05>
macro lenses of 100mm or 150mm start at 30cm
<DocScrutinizer05>
but I don't need a 25mm sensor
<DocScrutinizer05>
35*
<DocScrutinizer05>
generally a macro lens is defined as "magnification >=1" which is just a question of lens focal length / min focus distance
<DocScrutinizer05>
of course a 20mm lens can do magnification=1 in a focus distance of 20mm
<DocScrutinizer05>
s/object has 150mm distance from sensor/object has 150mm distance from LENS/
<DocScrutinizer05>
then (about same time) I started considering firmware hacks
<wpwrak>
(dl24) that 10 mm focus range is probably at 24 mm. at tele, the ratio may not be so good. but i guess you'd have to try it. that's the sort of stuff you don't find in specs, and even reviewers don't do much testing of macro.
<wpwrak>
for firmware hacks, i think canon (with chdk) still rules
<DocScrutinizer05>
>>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) <<
<wpwrak>
well, not too bad
<DocScrutinizer05>
so yes, "wide angle position" is ,ost likely "24mm zoom"
<DocScrutinizer05>
I'm however more interested in the other "option"
<DocScrutinizer05>
[2017-01-14 Sat 21:00:25] <DocScrutinizer05> if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification
<DocScrutinizer05>
aiui "effective 2000mm lens" means a 35/4mm object would fill the sensor's diagonal?
<DocScrutinizer05>
well, nope wait
<DocScrutinizer05>
meh, that math
<DocScrutinizer05>
let's start with 500mm lens, which means a single lens 500mm from sensor focuses parallel ("infinity") light to the sensor
<DocScrutinizer05>
so if you can focus this lens to an object 500mm away, you get a magnification of 1.0, right? IOW an object size of the sensor will fill the picture
<DocScrutinizer05>
now we're roughtly with my flawed math above: the cam does 4 times digital zoom, making the sensor smaller. and the focus distance isn't 500mm but 700mm
<DocScrutinizer05>
sensor size 1" (I assume that's diagonal?), so when magnification is "area" (is it?) we have an effective 1/2" sensor with digital 4x zoom, so a 0.5" object should fill the sensor diagonal, which is just within my requirement specs
<DocScrutinizer05>
but then lens length is usually standardized to 35mm 'sensor', not 1"
<DocScrutinizer05>
puzzling shit, makes me dizzy
<DocScrutinizer05>
on the bright side, it seems the DL24-500 is waiting to suffer some thorough tests in next Saturn market
<wpwrak>
well, they usually specify the equivalent
<DocScrutinizer05>
yep, that's what I meant
<DocScrutinizer05>
so when I use a 'fake' 500mm lens length value, I'd also need to use a 'fake' 35mm sensor, right?
<DocScrutinizer05>
not 1"
<DocScrutinizer05>
so an object of 35mm size would fill the sensor diagonal of DL24-500 when placed 700mm from lens surface in tele macro mode
<DocScrutinizer05>
unless we apply digital 4x zoom
<DocScrutinizer05>
well, actually 700/500 * 35mm
<wpwrak>
isn't it 700 from "film" (sensor) surface ?
<DocScrutinizer05>
nope, I think that's from lens surface
<DocScrutinizer05>
so I guess it's possibly correct to assume an object of 35mm *7/5 size would fill the diagonale of the 20.8 million px DL24 sensor, when placed a 700mm in front of lens surface in tele macro mode
<DocScrutinizer05>
zooming in digitally might still yield somewhat useful video (for work) at 10 times that, so a 3 to 4mm would fill the monitor diagonal
<DocScrutinizer05>
et a ~600*400 resolution
<DocScrutinizer05>
and 70cm is more than enough headroom for all tooling like soldering irons etc ;-)
<DocScrutinizer05>
WOW, Saturn makes that DL24 a sent from Starship Enterprise: viewfinder 2359 Megapixel
<DocScrutinizer05>
should suffice for proper holograms