Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.5 Official Beta Discussions Thread
Version 4.5 is now released, so this thread is closed, and a new one will be opened for 4.6. This one will be left around for archival purposes.
Dean Roddey
Explorans limites defectum
(reserved 1)
Dean Roddey
Explorans limites defectum
(reserved 2)
Dean Roddey
Explorans limites defectum
Well, I started climbing the next mountain today. I got a good bit done on converting the gesture stuff over to supporting the native inertial dragging scheme. So far I've just got the basic re-working of how incoming gesture events are processed, to let the target widget indicate does it want inertia or velocity and does it want to allow horz and/or vert panning. Based on that response I decide whether to treat it like the current flick type (which is all that makes sense in something like the CAB as it stands or in an overlay if page mode is enabled) or to allow full on inertial dragging.

And of course RIVA 1 clients can only send flicks so I still have to handle them from those guys, even for those widgets that would otherwise be able to handle the new dragging thing. The RIVA 1 server will just never send anything but flick type gestures into the IV engine

I've basically got it working again in those cases where it reverts to flick type gestures. Now I have to implement the actual dragging stuff in the widgets that can support that.

Of course it's never simple. The easy way to do it would be to just let those scrollable widgets just maintain a memory image of their own contents which are kept up to date at all times, and the dragging just lets you move around what part of that contents is visible. But that's not going to work. Some would be far too large for that to be practical.

A media list of, say, 30000 titles, which is, say, 512 pixels wide, and say, 20 pixels high per item, would be 60M pixels, times 4 bytes per pixel would be 240MB just to hold a simple text list. That's not practical.

The flick style gestures never move more than 1 page's worth, worst case. So I can just draw the current page plus another page into memory and slide that (and I know which direction it is because I don't have to react until the gesture is known.) But now, you could do a drag all the way across the screen and release still moving fast, which means lots of inertia in addition to the whole screen's width of dragging you already did, so there's no telling how far that might actually have to move in the end. And you can go in either direction once you start and I have to react to that immediately. So I have to be able deal with the farthest you could fling the contents in any direction the widget supports.

So I'll have to be more clever about things in some cases. For overlays I may just allow the overlay to maintain its complete contained template contents in memory all the time and let them stay updated all the time. And just let you move that around to expose whatever part of it you want via the overlay's 'portal'. Or I could draw the whole thing into memory when you start the gesture, but that may be slower to respond.

For others like the tool bar or media cat browser, they won't ever be that big so I can just quickly draw the whole thing into memory at the point where you do the gesture and slide as far as required. But, those two are handled by the same h/v list browser base class that would have to handle the big list as well. So for the list browsers I'll probably have to just generically go with the 'figure out a more than worst case distance' and load into memory enough on either side of the current page to deal with that.

The super-clever way would be to just have more drawn as it's required. But that would be much more complicated and could pick up something that changed while the drag was happening, while the part already drawn into memory is still reflecting the reality at the point of the drag starting. And it could tend to make the dragging glitchy as time is taken to redraw more into memory. And the memory bitmap would have to be big enough to draw more into anyway so I might as well draw all that I could possibly need and be done with it.

Am I rambling?
Dean Roddey
Explorans limites defectum
Uh, yes?

But a thoroughly enjoyable read. Sometimes it's good for us to see the mental decision process at work so we actually realize you don't just get out of bed and wave your wand around a little.

Flamin' Noobie...
Warp speed now and don't give me any of that dilythium crystal crap!
Oh, just as an aside, the licenses we are issuing now don't include the betas. I.e. where before we've have issued licenses for 4.4 that went up to, but didn't include, 4.5, so it would cover all the official releases and betas up to 4.5. But now we are doing up to but not including 4.4.900, which includes any official releases but not any betas.

So, the betas are only available to those who are covered under the maintenance system, because it will now require you get a new license to move beyond the official 4.4 release.

The purpose for this is that we've had issues where folks have upgraded to betas, but weren't covered, and had gone far enough not to be able to easily go back, but weren't able to move forward to the official release because they were covered. But we don't support beta releases once the official release comes out.

So this is intended to catch that issue early, before it becomes an unwitting issue for folks who aren't aware of the issues. They'll have to get a new license to move forward, so if they aren't covered we can let them know immediately before they start making changes based on new features. They can make a decision then to either go back or catch up on their coverage.
Dean Roddey
Explorans limites defectum
The other thing that the above stuff implies, which I hadn't considered, is that lists can no longer be like they are now, always evenly aligned on an item. They have to be able to move to arbitrary positions. So they have to change from a display slot/index orientation to a pixel oriented positioning scheme. So it changes things all around.

But the pixel oriented scheme is probably ultimately simpler and has fewer special cases anyway, so probably for the best. But it does make for a pretty basic change in how they work.
Dean Roddey
Explorans limites defectum
I'm at the point where tomorrow I can start testing the h/v list browsers with the native inertial dragging stuff. I'll get this scenario working, which gets me the list browsers, media cat browser, and the media item browsers all from one base class. And use that as the template for how to approach the others.

I also discovered that, now that everything is double buffered, an evolutionary complication is no longer required. It might be complicated to get rid of it, but it would simplify things a lot, so it would be worth it in time/complexity saved over the vast stretches of future time. I dunno.
Dean Roddey
Explorans limites defectum
OK, well after a lot of messing around with variations, I basically have the h/v list browser stuff working, though I'm not yet dealing with the possibility of big lists (and hence having to only draw part of the list into memory for scrolling.) I just wanted to work out the basics first. But I can now drag and fling and such and everything goes were it's supposed to go. And I simplified it in a number of ways over what it was before as well, which is good.

Tomorrow I'll work out the big list issues, and get the flick type gestures (for RIVA support) working again on these guys. Then I can move on to the next scrollable widget type. The others should be a bit easier.
Dean Roddey
Explorans limites defectum
OK, after a couple of days of ripping my hair out (virtually, it's not actually long enough to pull, thankfully), I've got the code basically done for the h/v browser based widgets to deal with big lists. I need to check out the horizontal and transparent/non-transparent variations, but basically it's working correctly on a long vertical list. I just set up (up to) two full virtual screen width/height's worth of content, which should be further than even an Olympic Gesture Team could fling it.

It gets stupidly complicated. Just the basic scenario of building the whole list into memory involves four or five coordinate systems that have to be translated between to get things done. You have the widgets relative to the template, which is relative to the window. And then the virtual list that is moving 'behind' the list widget and showing a particular part through. And the then zero based memory image of the list that has to be drawn itno and moved around during gestures. Dealing with a partial list in memory adds another couple to that. You can sit there all day and not realize that one calculation is wrong at some step in the process, and that's why you don't see the right stuff. It can drive you crazy.

But, thankfully that's the only one. Well, I take that back, the media list browser would have to be done this way as well, but at least I have a model now to go by.

One thing I need to decide is whether I'll stop responding to movement once your finger goes beyond the bounds of the widget. It can be kind of convenient to allow you to move however far you want without a flick, i.e. drag it further than you could if limited to the bounds of the widget itself. How do other touch screen programs work in this respect? Can you drag beyond the bounds of the thing you are panning and it keeps moving?
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  6.x Beta Release Discussions Thread gReatAutomation 29 5,164 10-05-2022, 05:54 PM
Last Post: Shaky
  Official 5.5 Beta Release Thread Dean Roddey 46 16,767 09-23-2021, 03:32 PM
Last Post: jokermac
  Official 6.x Beta Release Thread Dean Roddey 2 1,361 04-16-2021, 05:55 AM
Last Post: Dean Roddey
  5.5 Beta Discussions Thread Dean Roddey 291 82,079 04-05-2021, 04:10 PM
Last Post: Dean Roddey
  6.X Discussions Thread gReatAutomation 1 1,147 04-01-2021, 03:23 PM
Last Post: Dean Roddey
  Official 5.4 Beta Discussion Thread Dean Roddey 441 179,491 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 33,201 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 393,407 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 20,757 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 157,771 10-14-2017, 07:57 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)