Amiga ACS 1998 #4

home *** CD-ROM | disk | FTP | other *** search

/ Amiga ACS 1998 #4 / amigaacscoverdisc1998-041998.iso / utilities / shareware / workbench / fblit / fblitgui18.doc < prev

Wrap

Text File | 1998-03-06 | 12.8 KB | 410 lines

FBlitGUI 1.8 ------------ 'FBlitGUI' is © Stephen Brookes 1997-98 It Ain't My Fault! ------------------ This software offers many ways for you to corrupt data on, crash and generally do harm to your computer system! Don't even think about executing this! I will not accept responsibility for any unwelcome effects attributable to the use or abuse of any information or software in this archive. Distribution ------------ 'FBlitGUI' is freely distributable. (why?) Required -------- FBlit v2.4 MUI ?.? Installation ------------ Install in the same directory as the 'FBlit' executable. Usage ----- Launch 'FBlit' twice to access the GUI. That's Interesting ------------------ FBlitGUI (fbg) is not really a user interface for fblit, and there has been some debate wether or not to include it in this archive. It is a development and debug tool for me, but it can provide usefull options and information for anyone mad enough to touch it, so it is here. Being a dev tool, many pointless options and stats are available, and the majority of them have the capacity to corrupt and crash your system! I am NOT jokeing about this! Careless use of this software could easily cost you the contents of your hard drive! Basically --------- FBG presents an interface rather similar to 'standard' MUI prefs programmes, in style at least. This is rather missleading, there are some important differences! Almost all of fbg operates in 'real-time'. Changes you make will be applied immediately, not through any 'use'/'save'/'test' gadgets as in most prefs. The 'quit' gadget refers to FBlit itself, not fbg, and you are advised never to use it. 'use', 'save' and 'cancel' function as you might expect. There is no menu, and no easy way of loading or restoring default prefs. The default can be restored by deleting 'envarc:fblit.cfg' and reseting your system. Hopefully, every gadget has bubble help, and all those that carry significant risk of corrupting your system should have the word 'dangerous' in it's bubble. In most(all?) cases, the corruption risk is only present if there is actually any relevent data in fast mem at the time. FBlit consists of several patches. Some are functional, some only there for development reasons. Each has a page in fbg. You must NOT use FBlits and FBlitGUIs from separate archives! Chip & Fast Data ---------------- Several patches offer options relating to the location of relevent data and in all cases an option exists to 'pass on' data to the original patched function. The original OS functions generally cannot handle data in fast mem, and will corrupt your system if presented with such data, so it is not advisable to set any fast data option to 'pass on' if there is any possibility of such data actually turning up. Note that 'fast' in here generally refers to any non-chip memory. Patch Installation ------------------ The 'Installed' and 'Activated' gadgets are present for all patches. The activation gadget is there so that a patch can effectively be disabled even when it cannot be un-installed (due to being over-patched). Both may be dangerous. Stats ----- The meaning of stats is not documented and may not be quite as indicated by the labels. Treat them with caution! The stats do not update in real-time, since to do so could cause feedback loops. They are updated via the 'update' gadget, but take into account that the act of rendering the gadget, and text, may alter the values itself. FBlit Page ---------- Nothing interesting here. FBltBitMap Page --------------- FBltBitMap is a fully functional BltBitMap patch. It can perform any 'standard' function of the original in chip or fast mem. It will also have a fit if presented with any non-standard bitmap structures! This appears to be the most common cause of trouble with fblit. Note that non-data (0, -1) planes are largely exempt from any settings. They are dealt with separately before any other considerations unless 'pass on' is selected. Chip Options ------------ Relating to any call with all planes of both bitmaps in chip mem. Set any way you like, for speed/multi-tasking-ability (FBBM never uses the blitter itself) Pass On ------- All operations are passed on to the original function. Process ------- All operations are processed. Pass On Complex --------------- Operations that involve reading both source and destination will be passed on, all others will be processed. This is probably the best option. FBBM is significantly faster than the original on simple operations but there is little to choose between them with complex operations on here. In any event, all non-data planes are processed. Chip Copy Processing -------------------- This relates to any copy or copy&invert call where the destination bitmap planes are in chip. Set this how you like, trade-off speed and visual disturbance. Always Pretty ------------- All planes will be rendered simultaneously, one full raster line at a time. Avoid Flicker ------------- All planes will be rendered simultaneously, but the render may be split. Never Pretty ------------ Planes are rendered sequentially, and may be split. Fast Data Options ----------------- Applies to any call with any plane outside chip mem. Pass On ------- The call is passed on to the original function. Often a bad idea. Process ------- FBBM will process the call. Good stuff. Discard ------- The call is ignored. FBltClear --------- This is another functional patch, but it's not clear that there is any advantage in it, other than stopping fast calls reaching the OS though I can't ever remember seeing a fast call anyway... Chip Data Options ----------------- Pass On ASynch -------------- Operations that the calling programme is not going to wait for will be passed on to be done by the blitter, all other calls will be processed. see FBltBitMap for function of other options. FBltTemplate ------------ This is just a dev patch. It's only function is to stop fast calls reaching the OS and corrupting the system, and to show if any occur. Options as for FBltBitMap. FBltPattern ----------- Another largely non-functional patch. It's mainly here to block fast calls, but, if set to 'process', it will do operations of one particular type. Namely, calls where drawing mode is JAM2 and no area pattern or mask are specified. In practice this call draws a filled rectangle and it's not apparent why it gets used for this, it may be the OS. For the one function that can be processed it simply calls BltBitMap, so FBltBitMap settings may effect this one too. All other fast data calls are discarded when in 'process' mode. FBitMapScale ------------ This is fully functional, but doesn't get much exercise so it's not known how bomb proof it is. Note that the output of this function is never likely to be identical to that generated by the original, and it may also call BltBitMap. Options are pretty standard by now. FAllocMem --------- This is an integral part of FAllocBitMap. It has no function other than servicing calls from FABM. Don't install or remove them individually. FAllocBitMap ------------ This is the one responsible for forceing other software to allocate bitmaps with planes in fast mem (here I really do mean #MEMF_FAST). It maintains a list of tasks to be effected, either by inclusion or exclusion, in the promotion process. Only calls that do NOT specify #BMF_DISPLAYABLE will be effected. It's a somewhat rough process and there are probably many possible sources of trouble in here. Also note that this does not multitask. Only one calling task may be effected at a time, any other callers will have to wait their turn. This patch, and FAllocMem, can fairly safely be removed, installed etc. Config Page ----------- Task Logging ------------ The names of tasks that make an applicable call to Allocbitmap may be logged for user selection. This is not exactly efficient and should be disabled when not needed. Task List Options ----------------- Include ------- Tasks listed on the include list will be effected. Exclude ------- All tasks except those listed on the exclude list will be effected. Lists Page ---------- This part of the GUI does NOT operate in real time. Changes made here will only take effect on exiting the GUI via 'use' or 'save'. Note that task name are case sensitive. Include List ------------ Add --- Enter the name of a task to be added to the list here. Or select the pop gadget and choose from the logged task list. Note that the pop list is fixed at fbg run time. To update it you must cancel the GUI and restart. Remove ------ Delete a task from the list. Ho hum. Exclude List ------------ see 'Include List' Hmmmm ----- FBlit's default is to have everything turned on, and several programmes promoted to fast mem, but you can set it up in different, limited, ways. You can un-install all the patches except 'FAllocMem' and 'FAllocBitmap' to get a more restricted version of MCP's memory patch. (so what) If you un-install everything except 'FBltBitMap', and set it to 'pass on' fast data, you will have a slightly souped up CPUBlit. It will probably not be quite as fast at the few operations that CPUBlit actually does, but it is rather more wide ranging. Set up like this, it will also tend to work on systems where the full setup causes trouble. Doing anything like that obviously removes the possibility of running stuff in fast mem on a standard amiga. Promoting Stuff --------------- I really didn't want to get involved with 'retro-fitting' the use of fast mem, but it was unavoidable of course. Any software that offers an 'RTG' switch stands some chance of working with fblit on a standard amiga, but such software is rather scarce. (stuff designed to run under cgfx etc. will probably not work) In theory, all you have to do to force a programme to use fast mem for non-displayable bitmaps, is to add it's task name to the FAllocBitMap task list, but it is not likely to work in practice. The vast majority of software cannot be forced into fast mem for many reasons, and in any case, a lot of software wouldn't benefit much from it. For a start, there are probably many more OS functions using the blitter. If the programme uses any of these, it cannot be promoted. Any task that runs a GUI is quite likely to fall under this. The tasks that are promoted by default are ones that do not (AFAICT) generate a GUI. IPrefs is only responsible for allocating the source bitmaps for wbpatterns. The browsers all spawn a separate task to deal with images, and it is these tasks that are promoted, not the browsers main task. There will be more programmes that can be usefully promoted, but I haven't looked arround much. Multiview is one I have tried, and it illustrates some of the problems. I won't guarantee success with it, and this is only of use if you use mutiview to display images or anims in a window, but this is how to go about adding it to the list... Bring up the GUI, enable task logging on the FAllocBitMap page and exit the GUI via 'use'. Now launch multiview from its wb icon (not cli!) and view a picture (a large jpg) in a window, on a nice deep screen. Scroll about the image a bit, and note your Chip mem. Bring back the GUI and go to the FAllocBitMap/Lists/IncludeList page. Pick the poplist gadget and look at the list. You should see the names 'AsyncLayoutDaemon' and 'MultiView'. Pick the 'Async..blah' one to add it to the list, and exit the GUI again via 'use'. Now launch multiview again, as before. Same picture. Scrolling it this time, you may notice it is much faster. You also should be using less chip mem. Isn't that nice. Hmmm. Well, it still uses loads of chip mem though, so how about adding the 'MultiView' task to the list as well. What happens if you do, will depend... While I was running MUIASL, promoting 'MultiView' would cause corruption whenever the MUI file requester appeared. I'm back on default ASL now, and it seems to be stable with multiview promoted, but I have found out before that something can appear stable for weeks, and then all hell breaks loose at some time when you have loads of screens open etc. so no promises. Now, if I view a jpg in a window on here, with 'MultiView' and 'AsyncLayoutDaemon' promoted, it uses virtually no chip mem at all, but IFF and GIF still use plenty... If you try this, you will run into yet another problem. The task name of multiview is not constant. I specified running it from its wb icon. If you use a cli the task name will be whatever the command you typed was, so it could be 'sys:utilities/multiview' or maybe 'multiview' etc. which will not get promoted unless you also add those task names to the list. Enough Already -------------- see FBlit24.doc for contact etc.