cjp@vax135.UUCP (04/03/87)
I glimpsed one of the new IBMs on TV this morning (don't know which one), it was running a "circles" demo. They were drawing circles at about 2 per second. My stock Amiga can run ellipses (not just circles), in a full-screen window at over 10 per second, and much faster in smaller windows. This is IBM's 1988 machine? I think the Amiga is not in any trouble from this quarter. Charles Poirier
rap@dana.UUCP (04/07/87)
In article <1825@vax135.UUCP>, cjp@vax135.UUCP (Charles Poirier) writes: > I glimpsed one of the new IBMs on TV this morning (don't know which one), > it was running a "circles" demo. They were drawing circles at about > 2 per second. My stock Amiga can run ellipses (not just circles), > in a full-screen window at over 10 per second, and much faster > in smaller windows. This is IBM's 1988 machine? I think > the Amiga is not in any trouble from this quarter. > > Charles Poirier I talked to DUCK at one of the BADGE meetings recently and he mentioned that all of the circle code actually uses WritePixel. It could have been faster (and someday somebody will make it faster, I'm sure) but the pressures of the release time only allowed the crew to just barely get the code into 1.2. The benefit of doing it exactly the way the code is now is that it gave the Amiga one-dot-mode, which allows the blitter to be used most efficiently for filling the ellipses. I can envision at a future time somebody allocating a background bitmap, rendering (and filling) the ellipse in the background by the most efficient method available, then blitting (ClipBlitTransparent?) the resultant ellipse into the target area. I would assume that the result would be faster than the writepixel-per-dot than is now done? Rob Peck hplabs!dana!rap .
kinner@wsucshp.UUCP (04/11/87)
I can envision at a future time somebody allocating a background
bitmap, rendering (and filling) the ellipse in the background by the
most efficient method available, then blitting (ClipBlitTransparent?)
the resultant ellipse into the target area. I would assume that the
result would be faster than the writepixel-per-dot than is now done?
Great! Then maybe someone can teach Intuition to do its window rendering
into portholes. (Could bols ewhacs give us a demo of this sometime?)kim@amdahl.UUCP (04/14/87)
In article <160005@wsucshp.UUCP>, kinner@wsucshp.UUCP (Bill Kinnersley ) writes: > > Great! Then maybe someone can teach Intuition to do its window rendering > into portholes. (Could bols ewhacs give us a demo of this sometime?) One of the Mindscape games (Sinbad, I think) does something like this with the magnifying-glass, if I understand you correctly. Of course, I have no idea what technique they're using ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
jesup@steinmetz.UUCP (04/14/87)
In article <160005@wsucshp.UUCP> kinner@wsucshp.UUCP (Bill Kinnersley ) writes: [Someone wrote this, I don't know who. REJ] > I can envision at a future time somebody allocating a background > bitmap, rendering (and filling) the ellipse in the background by the > most efficient method available, then blitting (ClipBlitTransparent?) > the resultant ellipse into the target area. I would assume that the > result would be faster than the writepixel-per-dot than is now done? This is already possible, in two different ways: 1. Use AreaEllipse and a TmpRas to do a filled Ellipse using current drawing modes. Internally, this writes an ellipse into the TmpRas (I presume using DrawEllipse, and thus WritePixel. Not too bad, though, because no clipping need be done. Then it blits the AreaPtrn into the destination using the area fill mode of the blitter. Note that the drawing modes DO apply, so you can do things like COMPLEMENT, etc. Minor bug: AreaEllipse won't draw an outline in the AOlPen color. 2. Draw the Ellipse in a private RastPort, Flood fill it, (or use your own fill/draw routines), then use ClipBlit (or if it's in a BitMap, use BltBitMapRastPort) to blit it into the destination. >Great! Then maybe someone can teach Intuition to do its window rendering >into portholes. (Could bols ewhacs give us a demo of this sometime?) This is a seperate question, having to do with the layers library. It would be nice to be able to specify the clipping for a RastPort by a BitMap, as well as with rectangular bounds. Essentially, all blits to the RastPort would use 3 sources, not the more common 2. The equation for the Blit would be (assuming a is the mask, b is the source, c is the second source (usually the same as the destination), and the result goes in d): D = (A)(old_equation) + (NA)(C) Where old equation was something like: D = (B)(NC) + (NB)(C) where (NX) == not X ("Cookie Cut" blit, 0x60) This would mean Most standard user Blits use two sources, B & C, with B = the source and C = the Dest. (Ex: ClipBlit, BltBitMapRastPort, etc). Any Blits that used all three sources, or that didn't use the destination as a source, would have to broken into two Blits. All of this could be hidden from the user, as are the multiple blits used for ClipBlit and BltBitMapRastPort, used to handle the rectangular Clipping regions. It might even be faster, as Blits might not have to be Clipped by code. There are some drawbacks, though: Extensive rewrite of the layers library, and calls like ClipBlit. Potentially large memory use for rastports using this feature (at least 1 full extra bit-plane.) Potential problems dealing with the rewrite of code (probably won't always be totally transparent, though we can try.) It all depends on whether it can be hidden in the layers library. In any case, it shouldn't effect old code at all. I definitely think it's worth investigating. I've been trying to find ways to do things like this for a while, and the closest I've come without playing with the blitter directly or useing several levels of indirection is the new call BltMaskBitMapRastPort, in which the source must be a bitmap (as opposed to a rastport, ala ClipBlit), and the mask must be the size of the source BitMap. If I want to Clip bitmap blits to rastports, it'll do, but it's not the same as what the layers library does. Any Comments or better ideas? Better yet, any volunteers? Will it work at all? Randell Jesup jesup@steinmetz.uucp (seismo!rochester!steinmetz!jesup) jesup@ge-crd.arpa