However, this wasn't an akademic exercise, and actually not really a part of the Natami development (though see below!). The point was more to advance JPEG as a standard. If you don't know, I'm a member in this club, and this is something a subgroup of us is currently looking into. So it requires a demo code to trigger the interest of the committee. And there it is:

EXTERNAL LINK 
The login name is "anonymous", then password is "jpeg".

The bug tracker is here:

EXTERNAL LINK 
The cool and new feature of this code is "lossless coding", and 12bpp support (HDR-image support), that is, you can now code your images without loss in JPEG, fully backwards compatible. Which means that all existing implementations will be able to view the images all right, though likely with a minimal loss. If you do not tolerate any loss, you need to decode with this codec.

The code is free software, released under GPLv3, ready for everyone to look at, use and compile. And if you check out how the codec works, you'll clearly notice my Amiga background: Tag lists and hooks all over the place, but now in nice C++.

Unfortunately, I was not able to add a couple of nice tricks to make it faster. As this codec was partially paid for by my industry partners, I cannot release all their technology for free. (Only some. (-;)

Anyhow, have fun. And probably someone wants to turn this into an Amiga datatype, or a library.

Thus, what you can do is run another task, forward a message from the input.device task to that task, and do the operations from there so you cannot deadlock. The signalling between the commodity handler and the worker task should then be asynchronous, of course.

gone gahgah wrote:

The reason I'm contemplating it is so that I can draw my own menu strip and also so that I can bypass the 32menu*64item*32subitem limits.

It is only a limit in so far as event signalling goes. But anyhow, if you have more than 64 items or 32 subitems, you have a usability problem in first place. Menus should never grow that large.

So long,
Thomas

gone gahgah wrote:

What would likely happen if the commodity intercepted the menu button,

How do you do that? As far as I remember, Cx sits behind the intuition input handler, and thus only receives "cooked" events intuition already worked on, so you cannot intercept them. For that, you need an input handler ahead of intuition, but then you don't know whether you received a RMB for a menu. Or you do, but then need to implement *all* the intuition handling yourself, i.e. RMB trap Double RMB requester, MenuVerify etc... MagicMenu tried this, and of course, failed to run reliable.

gone gahgah wrote:

found the window the mouse was over,

How do you do that? The problem is here that the window arrangement is in the hands of intuition. What you can do is *lock the layerinfo*, get from the mouse position the layer it is on (WhichLayer()) from there work upwards to the window. But this information doesn't help you much because you cannot ensure that the pointer you receive remains valid at the time you use it - only intuition can. And you cannot lock intuition for the pointer to stay valid because then you cannot call intuition functions. It is the classical intuition "chicken and egg" problem.

gone gahgah wrote:

and directly set its WFLG_MENUSTATE (after activating the window like autopoint), before drawing menus (instead of Intuition), and then undrew the alternate menu and cleared the flag when the menu button was released?  Would you know of some of the likely side-effects (including crash?)

It would "work" in the same sense MagicMenus "worked". Which means, with a lot of effort, you could make it work "most of the time", with potential race conditions, and potential compatibility issues (MagicMenus never implemented the intuition MenuVerify logic correctly, for example - it could not, due to reasons I indicated above).

gone gahgah wrote:

Does the WFLG_MENUSTATE flag stop any drawing into the screen while the menu is active?  (I'd like to support both screen blocking and non-blocking options for menus).

I don't know, but I would believe that intuition rather sets this flag than looking at it.

In a program, what *you* can do is to enable the MenuVerify IDCMP messages and then react on what you get from intuition. Or, possibly better, just set RMBTrap and instead of rendering menus by intuition, open borderless windows that look like menus. *This* works. It would be inconsistent with the rest of the system, and the menus wouldn't look like intuition menus, but it is waterproof and valid. One would probably have to play a bit with the window input focus now that I think about it, but this seems solvable.

Thomas Richter wrote:

How do you do that? As far as I remember, Cx sits behind the intuition input handler, and thus only receives "cooked" events intuition already worked on, so you cannot intercept them. For that, you need an input handler ahead of intuition, but then you don't know whether you received a RMB for a menu. Or you do, but then need to implement *all* the intuition handling yourself, i.e. RMB trap Double RMB requester, MenuVerify etc... MagicMenu tried this, and of course, failed to run reliable.

Thomas, the CX input handler is before the Intuition input handler in the chain. EXTERNAL LINK  So all the events are raw and the input chain can be changed in the ways you mentioned.  MagicMenu did have problems though.  I thought MagicMenu actually illegally patched Intuition?

gone gahgah wrote:

found the window the mouse was over,

Thomas Richter wrote:

How do you do that? The problem is here that the window arrangement is in the hands of intuition. What you can do is *lock the layerinfo*, get from the mouse position the layer it is on (WhichLayer()) from there work upwards to the window. But this information doesn't help you much because you cannot ensure that the pointer you receive remains valid at the time you use it - only intuition can. And you cannot lock intuition for the pointer to stay valid because then you cannot call intuition functions. It is the classical intuition "chicken and egg" problem.

I already do that with my 'mousezone' commodity using the process you describe.  This is the same as how autopoint works too.  The input event comes with a mouse position which is what Intuition receives as well.

gone gahgah wrote:

and directly set its WFLG_MENUSTATE (after activating the window like autopoint), before drawing menus (instead of Intuition), and then undrew the alternate menu and cleared the flag when the menu button was released?  Would you know of some of the likely side-effects (including crash?)

Thomas Richter wrote:

It would "work" in the same sense MagicMenus "worked". Which means, with a lot of effort, you could make it work "most of the time", with potential race conditions, and potential compatibility issues (MagicMenus never implemented the intuition MenuVerify logic correctly, for example - it could not, due to reasons I indicated above).

I'm only hoping to do it for apps that are specifically programmed to use the new menus.  I'd leave the rest be handled as normal.  Would that work?

gone gahgah wrote:

Does the WFLG_MENUSTATE flag stop any drawing into the screen while the menu is active?  (I'd like to support both screen blocking and non-blocking options for menus).

Thomas Richter wrote:

I don't know, but I would believe that intuition rather sets this flag than looking at it.

Intuition would set it for some purpose.  The description for the flag says "Window is active with Menus on".  I was just seeing if you might know.  I guess I can test it by adding a "watcher" to my MouseZone commodity that specifically tests this and try different things.

Thomas Richter wrote:

In a program, what *you* can do is to enable the MenuVerify IDCMP messages and then react on what you get from intuition. Or, possibly better, just set RMBTrap and instead of rendering menus by intuition, open borderless windows that look like menus. *This* works. It would be inconsistent with the rest of the system, and the menus wouldn't look like intuition menus, but it is waterproof and valid. One would probably have to play a bit with the window input focus now that I think about it, but this seems solvable.

It would be system problem free but then you have to wait for the program to process the events which could make it feel laggy.  That's what I want to avoid.  For example, I've designed the zoneclass 'gadgets' to avoid causing lagginess by being able to delay their rendering so that they don't cause any lag to the input chain.

I'll try to get to testing this flag hopefully sometime soon.

Would it be possible & make sense to write it in Assembler to achieve the ultimate goal , save space & execution time or would it be almost equally in size & execution speed if one would use C(++) ( , python , ) and assembler , in a mix - as it happens most of the time ?

How much time would it take on our platform to give it The Best in jpeg codec programming ?

gone gahgah wrote:

I already do that with my 'mousezone' commodity using the process you describe.  This is the same as how autopoint works too.  The input event comes with a mouse position which is what Intuition receives as well.

Oh, sure, but this causes a race-condition: You do not know whether the window pointer you have is actually valid the time you run into an ActivateWindow(). IOWs, Autopoint is not safe and may crash the system. If the window goes away between the test of autopoint, and the actual call of ActivateWindow(), you'll be doomed. Since we're multithreaded, this may actually happen.

gone gahgah wrote:

I'm only hoping to do it for apps that are specifically programmed to use the new menus.  I'd leave the rest be handled as normal.  Would that work?

I wonder what the requirements for such applications would be. Honestly, I don't know.

gone gahgah wrote:

I was just seeing if you might know.  I guess I can test it by adding a "watcher" to my MouseZone commodity that specifically tests this and try different things.

Well, while I don't know exactly intuition uses this flag internally, but the reason why nothing else can be drawn on the screen while the menu is active is a different one: This is a side effect that intuition holds the LayerInfo lock of the screen the window is on, which prevents other layers (and hence windows) to be created on top of the menu.

gone gahgah wrote:

It would be system problem free but then you have to wait for the program to process the events which could make it feel laggy.

Fair enough, question is whether it matters.

So long,
Thomas

Just to give you an idea: There is always new hardware coming out you can adapt to, and for that reason algorithms always change a bit. I have here my own JPEG 2000 codec I'm working on, actually more or less since the last ten(!) years. I wouldn't call it optimal. Just damn pretty good. (-;

For JPEG, the story is about the same: The professional JPEG (not the implementation I linked to above) also has a history of about the same time, even a bit longer. I would neither call it "optimal", but you'll have a pretty hard time finding something faster and more robust.

Jacek Rafal Tatko wrote:

Would it be possible & make sense to write it in Assembler to achieve the ultimate goal , save space & execution time or would it be almost equally in size & execution speed if one would use C(++) ( , python , ) and assembler , in a mix - as it happens most of the time ?

I'm a bit scratching my head over this question. The question is not so much whether you could in principle, but whether you would. JPEG baseline is not so big, so this is a doable project. Complete JPEG (and not just the stuff everyone does) is considerably larger and complex. What I linked above is a *complete* JPEG and not just the ... IJG gives you. That would take longer. JPEG 2000 would take incredibly long.

The problem is not really taking an algorithm and translating it line by line into assembler. You don't reach optimality this way. A bubblesort in assembler is still an O(N^2) algorithm, and still slow. Typically, you rewrite an implementation several times before it becomes ideal or you're at least happy about it. The wavelet transformation in my JPEG 2000 I wrote three times (or four times if you count in my latest archivements). You don't do that with assembler - refactoring is a must in projects such size, and refactoring in assembler is a headache.

Writing complex(!) software simply doesn't work by writing code line by line - it is an endless process of refactoring and improvement after improvement - it is a dynamic living piece of work, where assembly would slow you down to a crawl.

IOW, theoretically yes. Practically, you're likely dead before reaching the quality you reach in other languages.

Jacek Rafal Tatko wrote:

How much time would it take on our platform to give it The Best in jpeg codec programming ?

Is a full JPEG better than baseline only? I would say so. Does it take longer to optimize? I would say so. How long do you want to wait? That is the question. Not *when* to reach an optimum. You simply don't.

As I already said, there is no solution to this problem. It is a typical intuition design problem - unless *you* control the lifetime of the window, the window pointer helps little.

A similar problem appears in MagicMenu. There is no fix, and no patch, and it could actually not be any different. You are basically manipulating an object you do not own, and hence do not control the lifetime of.

It's not a problem for my zoneclass gadgets as I do ensure that there is a way to stop windows closing while the gadgets are being talked too so that is okay.  It may or may not be the problem either for moving newer menus outside Intuition into the commodities chain but there may be other problems that you have mentioned and suspect.  I'll have to test the idea out which shouldn't be too hard to do in a simple form.

But it would be a bit of a bummer for AutoPoint.  I can certainly guarantee that zoneclass compliant windows will stay around but I couldn't guarantee that for other windows.  Maybe what I'm doing could be a longer term solution at some point?  It is however illegal at the moment as I'm purloining a windows structure bit without official sanction.

I don't like doing unsanctioned aka possible future fail things either - including hacking Intuition like MagicMenu.