128 Slider/Faders Include Crossplatform - Redesigned

[WilliamL]

Remarkable!

and a lesson in OOP to boot

I haven't a clue...

[Andre]

Event testing is updated to include leftclick and you're right, it's quite useful. Now the only unanswered question is whether or not it's still working properly on Mac and Linux.

The "redesigned" code works fine now also on my MacOS 10.5.8

Means clicking on the trackbar (fader is updated after releasing the left mouse buttons) as well clicking inside the canvas does now correctly update the faders.... Well done! Thanks

[Joris]

Netmaestro or whoever is able, do you wont to enlighten this magic code part a bit more ?

How does one field of a structure (vTable) get multiple proc-adresses ?
It's just one pointer and so how can it receive multiple proc-adresses ? That's what's happening there I believe.
InitializeStructure has probably something to do with these I suppose, but...

Code: Select all

*this.FADER = AllocateMemory(SizeOf(FADER))
  InitializeStructure(*this, FADER)
  *this\vTable = ?FADER_Methods
  
   DataSection
   FADER_Methods:
   Data.i @Fader_Canvas(),
          @Fader_SetColumn(),
          @Fader_GetColumn(),
          @Fader_RedrawColumn(),
          @Fader_ProcessEvents(),
          @Fader_Move(),
          @Fader_Free()
 EndDataSection

I suppose, I can imitate this setup, but understanding what is going on, how much elements (proc-adresses) can be added and so on, that's another thing.

Thanks.

[Demivec]

Netmaestro or whoever is able, do you wont to enlighten this magic code part a bit more ?

How does one field of a structure (vTable) get multiple proc-adresses ?
It's just one pointer and so how can it receive multiple proc-adresses ? That's what's happening there I believe.
InitializeStructure has probably something to do with these I suppose, but...

Code: Select all

*this.FADER = AllocateMemory(SizeOf(FADER))
  InitializeStructure(*this, FADER)
  *this\vTable = ?FADER_Methods
  
   DataSection
   FADER_Methods:
   Data.i @Fader_Canvas(),
          @Fader_SetColumn(),
          @Fader_GetColumn(),
          @Fader_RedrawColumn(),
          @Fader_ProcessEvents(),
          @Fader_Move(),
          @Fader_Free()
 EndDataSection

I suppose, I can imitate this setup, but understanding what is going on, how much elements (proc-adresses) can be added and so on, that's another thing

It reflects the Interface. *vTable simply points to the start of a 'vector Table' which holds the addresses for all of the methods (in the same order) that were defined in the Interface.

Compare the table above with the interface code:

Code: Select all

Interface iFADER
  canvas()
  SetColumn(column, level)
  GetColumn(column)
  RedrawColumn(column)
  ProcessFaderEvents(*fader.iFADER)
  Move(x, y)
  Free()
EndInterface

The structure that is used and initialized is setup with at least one field, the *vtable, first. Any additional structure fields there differ according to the methods and interactions defined for the object.

[Joris]

It might sound silly, but I'm still wondering why the use of 127 images is needed ?
I originally had one image as source and all others are copies to one surface (BitBlt), for each type of fader, which can hold (in this case) 127 of them.
It's probably a matter of resources, but one big surface instead of 127 small ones wouldn't that make a big difference, if even more would be added ?

I'm thinking of a program in which a user can add his own bunch of faders, selecting one from a preset design and connect them with some function (like in a sort of form editor).

Code: Select all

Procedure New_Fader(x, y)
  
  fg_iCol = CreateImage(#PB_Any, 6, 128) 
  ...  
  For i=0 To 127
    temp = GrabImage(fg_iCol, #PB_Any, 0, 127-i, 6, i+1)
    *this\iLevel(i) = CreateImage(#PB_Any, 6, 128)
    StartDrawing(ImageOutput(*this\iLevel(i)))
      Box(0,0,6,128,$D1D1D1)
      Box(1,0,4,128,$EFD6AD)
      DrawImage(ImageID(temp), 0, 128-i)
      FreeImage(temp)
      For j=3 To 123 Step 4
        Line(0,j,4,1,$EF1010)
      Next
    StopDrawing()
  Next
  
  FreeImage(fg_iCol)
...

Thanks.

[netmaestro]

There is one image built and stored for each possible level. There would never be a reason to have more than 128 of them regardless of the number of columns in a fader. Each image is small and the memory used is negligible and the main benefit to this approach is speed. If these images were not pre-built and available, the code you're showing would have to be executed from GrabImage down to StopDrawing at every single mousemove. As it is, the image is chosen and blitted to the canvas and we're ready for the next one. No, this one is not negotiable, changing it would result in a serious performance drop.

[Joris]

There is one image built and stored for each possible level.
...

Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

[Fred]

There is one image built and stored for each possible level.
...

Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

Just to be clear, what do you mean by 'non-crossplatform BitBlt' ? PB DrawImage() uses BitBlt() on Windows, so did I miss something ?

[Demivec]

Just to be clear, what do you mean by 'non-crossplatform BitBlt' ? PB DrawImage() uses BitBlt() on Windows, so did I miss something ?

@Fred: He means that he thinks BitBlt() is the only way to accomplish the task but that it is non-crossplatform. He is looking for a way to draw a clipped image that would also be cross-platform.

[Joris]

@Fred: He means that he thinks BitBit() is the only way to accomplish the task but that it is non-crossplatform. He is looking for a way to draw a clipped image that would also be cross-platform.

Indeed, but also speed is quit important herein.
PB DrawImage() doesn't allow to take a part of the image, (it becomes resized instead of 'cut out').
(Pay attention I'm in a learning fase still.)

Maybe just a flag or a DrawingMode() : no_resize, could fix things.
Yet... x-y-w-h it still wont be complete.

[Demivec]

There is one image built and stored for each possible level.
...

Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

It would be great to have a convenient method of clipping a drawing. Still, I don't think it is too much of a speed hit to simply draw the portion again. This is what I did in the first code sample that I posted in your original thread requesting a solution to this need. The code did all of the things that you demonstrated you needed and seemed to function just fine. Refining it to add more customization or converting it to use an interface (as netmaestro did) would not be too difficult.

[Fred]

Ok, I see.

[Joris]

It would be great to have a convenient method of clipping a drawing. Still, I don't think it is too much of a speed hit to simply draw the portion again. This is what I did in the first code sample that I posted in your original thread requesting a solution to this need. The code did all of the things that you demonstrated you needed and seemed to function just fine.

Demivec, I have no comment on the code of Netmaestro or yours, but what I didn't tell...
All is based on this one example of fader image which was shown, while I also use more complex fader images and in more or less numbers, sizes and spaces between them.
These become moved while there is also a timer calling a proc (1/1000s), which may absolutely not become interrupted.
So, speed is very important in the first place, the timer-thing in PB is a later concern. I hope this makes a bit more clear. And, thanks again for the help, also on the interface explanation.

[Demivec]

Demivec, I have no comment on the code of Netmaestro or yours, but what I didn't tell...
All is based on this one example of fader image which was shown, while I also use more complex fader images and in more or less numbers, sizes and spaces between them.
These become moved while there is also a timer calling a proc (1/1000s), which may absolutely not become interrupted.
So, speed is very important in the first place, the timer-thing in PB is a later concern. I hope this makes a bit more clear. And, thanks again for the help, also on the interface explanation.

@Joris: You have made things clearer.


My comment was directed at the idea of speed. Netmaestro's code is a great demonstration of one way to accomplish the things you originally requested but has some challenges with speed of redrawing as it is currently implemented. All one has to do is move the trackbar up or down to notice this.

You mentioned some concern over why his code stored many images for displaying the column values and used the bitblt() functionality has a desirable thing, both for speed and ease of use.

I was trying to address the idea of speed also as well by reminding you that a previous code sample of mine simply redrew the column from scratch each time it changed and didn't store any images. It was simply to show that there were other options that were quick and uncomplicated. My intention wasn't to muddy the waters.

[Joris]

My intention wasn't to muddy the waters.

I was a bit scared for that and I don't wont that too.

Netmaestro's code is a great demonstration of one way to accomplish the things you originally requested but has some challenges with speed of redrawing as it is currently implemented. All one has to do is move the trackbar up or down to notice this.

Now that I understand his code for 99% I know it is the best solution in any way : nice image, speed, redrawings, etc. But doing a research is part of learning and that sometimes ends up in 'silly questions' (beside the need to translate my words and thoughts). Me, I'm used to BitBlt for this kind of things and find it still hard to believe it isn't included for a crossplatform way. I got to accept that, but sorry to say, it feels a bit like going backwards having no other solution. Maybe an elucidation : think about a nice audio volume meter...
(To substantiate a request, nothing more.)

Thanks.