| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| brendand | cnd, hey - i heard you might have some utility which allows me to experiment with MT touchscreen stuff without needing a touchscreen? | 15:40 |
|---|---|---|
| cnd | brendand: hmm? | 15:40 |
| brendand | cnd, something to record and play back touch events? | 15:40 |
| cnd | yeah, evemu | 15:41 |
| cnd | http://launchpad.net/evemu | 15:41 |
| cnd | you can use it to record input device events and play them back later | 15:41 |
| === dandrader|afk is now known as dandrader | ||
| dandrader | cnd, damn. I accidentally pushed directly to lp:frame when trying to update the merge request branch | 17:12 |
| cnd | dandrader: just back it out | 17:13 |
| dandrader | yep | 17:13 |
| cnd | no worries | 17:13 |
| cnd | just try to be quick about it :) | 17:13 |
| dandrader | cnd, done. and the merge request is now updated, by the way :) | 17:15 |
| cnd | cool, I'll take a look right now | 17:16 |
| dandrader | awesome | 17:16 |
| cnd | dandrader: it's pretty good, though what happens if a backend borrows a touch but then doesn't give it back? | 17:28 |
| cnd | we're left in a bit of an errant state | 17:28 |
| dandrader | cnd, yes. bad backend! | 17:28 |
| cnd | why can't we simply clone the touch, leaving it in the frame as it is | 17:28 |
| cnd | and then overwriting the frame's reference if the touch is given to it | 17:28 |
| cnd | this would always ensure invariance of the frame state | 17:29 |
| dandrader | because that's inefficient | 17:29 |
| cnd | how? | 17:29 |
| dandrader | by unnecessarily cloning a touch | 17:29 |
| cnd | actually, doesn't borrow_touch_by_id return the same touch, but wrapped in a new UFBackendTouch object? | 17:31 |
| cnd | if you change its values, doesn't it change the values of the touch for previous frames? | 17:31 |
| dandrader | cnd, so you propose UFBackendTouch to hold a UFTouch instead of a UFSharedTouch ? | 17:31 |
| dandrader | cnd, it depends | 17:32 |
| dandrader | cnd, if the UFTouch has only one reference. it's just updated | 17:32 |
| dandrader | cnd, if it has more than one reference, it's first cloned and then its clone is updated | 17:32 |
| cnd | ok, I remember that logic now | 17:33 |
| cnd | let me think a minute | 17:33 |
| cnd | it sounds like that's the main reason you have for the borrow semantics | 17:33 |
| cnd | that way the backend is the only one with a reference to the touch | 17:34 |
| cnd | thus it evaluates as unique | 17:34 |
| dandrader | cnd, right | 17:34 |
| cnd | if we change the rules slightly, I think it could still work and leave frame invariant | 17:34 |
| cnd | say when you update the touch values, it checks if there are only two references | 17:34 |
| cnd | one for the only usage in its frame, and one for the backend reference | 17:35 |
| dandrader | hmm.... sounds dangerous... making assumptions... | 17:36 |
| cnd | we can assert if the use_count is only 1, since that should never happen | 17:36 |
| cnd | and we are only using this check for the backend API | 17:36 |
| cnd | i.e. the built-in X11 backend shouldn't be interfered with | 17:37 |
| cnd | the only way I can see there being bad behavior is if: | 17:38 |
| cnd | the backend gets a reference to the touch | 17:38 |
| cnd | the ref count is now 2 | 17:38 |
| cnd | the backend deletes the touch, perhaps by giving it back to the frame | 17:39 |
| cnd | the ref count is now 1 | 17:39 |
| cnd | but then the backend reuses the touch, since it may still have a valid pointer value | 17:39 |
| cnd | but that's obviously very wrong :) | 17:39 |
| cnd | and besides, you delete the touch record altogether in frame_backend_frame_give_touch | 17:40 |
| cnd | so it shouldn't really be possible with explicit pointer shenanigans :) | 17:40 |
| cnd | s/with/without/ | 17:40 |
| dandrader | not giving back a borrowed touch is also very wrong | 17:40 |
| dandrader | so let me recap | 17:41 |
| cnd | of course, but it's merely a memory leak | 17:41 |
| dandrader | you want to s/borrow_touch/get_touch | 17:41 |
| cnd | rather than something that could potentially cause bad behavior on the frontend client side | 17:41 |
| dandrader | cnd, ^? | 17:42 |
| dandrader | and keep the give_touch? | 17:42 |
| cnd | yeah, I want to be sure that I can't take a reference to the touch, hold on to it, and hence screw up the client who will be all confused when it can't find the touch in the frame | 17:43 |
| dandrader | the client won't be confused | 17:43 |
| cnd | let's say there's a touch with ID of 5 | 17:43 |
| dandrader | because you're editing a frame for a event that hasn't even been created yet | 17:43 |
| dandrader | not alone sent to the client | 17:43 |
| dandrader | s/not/let | 17:43 |
| cnd | oh, but what if you do send the event on before you gave the touch back? | 17:44 |
| cnd | because of a bug | 17:44 |
| cnd | some of my thoughts here are due to similar bugs I've made myself in things like the X input modules | 17:44 |
| cnd | if there's a possibility that a touch may be "lost" in the state somewhere, it gets really hard to figure out what's going on, and it often leads to crashes | 17:45 |
| cnd | however, a touch getting "stuck", but leaving the rest of the state intact, usually just leads to some gestures stopping from working | 17:45 |
| dandrader | could you draft the API that you're proposing and pastebing it? | 17:47 |
| dandrader | It's not very clear to me | 17:47 |
| dandrader | how do you get a touch from a frame. and how do you get rid of that touch later on | 17:48 |
| dandrader | touh backend, that is | 17:48 |
| dandrader | and how you give a touch to a frame | 17:48 |
| cnd | the api is basically exactly what you've got | 18:03 |
| cnd | just that you don't "borrow" a touch by swapping references out | 18:03 |
| cnd | you simply give the backend a reference to the touch | 18:04 |
| cnd | then, when you change properties, you check if the use_count of the shared_ptr > 2, in which case you need to do a hard copy | 18:04 |
| cnd | I think that's all that needs to change | 18:07 |
| cnd | I guess in give_touch, you just need to add the touch to the frame, overwriting any touch that already is there for the same touch id | 18:07 |
| dandrader | I think that would just serve to hide bogus situations | 18:09 |
| dandrader | hmm | 18:10 |
| cnd | that's the point, really | 18:13 |
| cnd | making it less bad if you make a mistake in your backend code | 18:13 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | cnd, what I don't like about your implementation is that it adds dependencies between seemingly independent implementations. Now the UFTouchBackend lazy-copy scheme will be twisted because it knows that if refcount==2 it's because one of the refs is being held by UFFrame while the touch is being borrowed etc so please ignore it and consider as if the refcount was just one instead | 18:40 |
| cnd | yeah, I agree that part is a bit messy | 18:41 |
| cnd | If you feel strongly about it, I'm ok with your approach | 18:41 |
| dandrader | hmm, so it looks like we are coming to an agreement. Then could you please please finalize your review? :) | 18:48 |
| cnd | yeah | 18:58 |
| cnd | dandrader: I reviewed it | 18:59 |
| dandrader | cnd, thanks! | 19:00 |
| cnd | np :) | 19:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!