I need to deal very wide images, beyond the 16384-wide limit that Metal has. So, I've resorted to using Metal buffers to reorganize my pixel data. Even using a MTLTexture for output was failing due to purported issues with getBytes and texture syncronization on NVidia hardware.Anyways, below is a code snippet that works just fine for converting 32-bit RGBA data (with forced alpha) into my desired compact form. Both my input and output buffers are formatted for 32-bit RGBA data. My output buffer is actually a CVPIxelBuffer.If I change line 18 to deal with 24-bit BGR data instead -- the noted one, multiplying by 3 bytes/pixel instead of 4, all I get is a black image.I'm baffled as to why things are failing.kernel void stripe_Kernel(device const uchar *inBuffer [[ buffer(0) ]], device uchar4 *outBuffer [[ buffer(1) ]], device const ushort *imgWidth [[ buffer(2) ]], device const ushort *imgHeight [[ buffer(3) ]], device const ushort *packWidth [[ buffer(4) ]], uint2 gid [[ thread_position_in_grid ]]) { const ushort imgW = imgWidth[0]; // eg. 18000+ const ushort imgH = imgHeight[0]; // eg. 2048 const ushort packW = packWidth[0]; // eg. 1024 uint32_t posX = gid.x; uint32_t posY = gid.y; uint32_t sourceX = ((int)(posY/imgH)*packW + posX) % imgW; uint32_t sourceY = (int)(posY%imgH); uint32_t ptr = (sourceY*imgW + sourceX)*4; // change this to "*3" for 24-bit uchar4 pixel = uchar4(inBuffer[ptr],inBuffer[ptr+1],inBuffer[ptr+2],255); outBuffer[posY*packW + posX] = pixel; }I should mention that I allocate the input Buffer thusly:posix_memalign((void *)&diskFrame,0x4000,imgHeight*imgWidth*4);I've even left this as-is when dealing with 24-bit data thinking I may be having memory alignment issues on the GPU.I was previously using the Accelerate framework to convert my 24-bit source data to 32-bit source data (inBuffer) for use by Metal, but doing this conversion on the GPU should anecdotally be about 3x faster. This code could be much shorter if, say, inBuffer was also defined to be uchar4 or uint32_t, but I'm demonstrating a failure case.

I'm curious to know if anyone is aware of a developing standard in including real-time DMX lighting control data (ArtNet/E1.31) as a track to an existing Quicktime movie?At the AVFoundation level, rather than just pulling audio/video samples from a running AVPlayer, one would be be pulling this control metadata and sending it across the DMX network. One would likely using AVMutableMovie to effectively merge a basic audio/video tracked QTMovie with timed metadata. In actuality it would be a sample reference file linking to the AV-based movie file and would itself contain the timed metadata.I am aware of Tim Monroe's "Editing Movies in AVFoundation" (Session 506, WWDC 2015) where he melded his GPS location data whilst inline skating around Oakland & Boston with headcam videos over the years. I've downloaded the "AVMovieEditor" sample code (circa 2015) mentioned therein, but it's more than a tad dated.As well, "Harnessing Metadata in Audiovisual Media”, WWDC 2014" with the AVCaptureLocation and AVTimedAnnotationWriter sample code.I don't see an existing AVMediaType that would be a good fit for this lighting control data. I guess one can just invent their own data type, no?-- Bruce.

I have a PHP script running on a website which logs the number of times access is associated with a key:http://www.mywebsite.com/admin-query.php?key=8469f8847b8b4d05364ae400d4071d93If the URL is incomplete and I go to manually alter the URL in the top bar of Safari 13.0.5 (on MacOSX 10.14.6) , when the URL matches what was previously entered, before I even press return, I notice that the script has been run and my access tally associated with that key in MySQL database has been incremented.To be clear... altering the "admin-query" in the URL to "admin-query1" and then back again without pressing return causes the "Top Hit" and "Google Suggestions" popup to appear, at which point the PHP script is run.How can that be so?I've tested with Chrome 81.0.4044.122, and didn't see the same result.

I have an NSCollectionView specified as both my DataSource and my Delegate. I have two issues: 1) Rather than doing the registerClass method, attempting to instead use the 3 lines of commented code with the (non-nil) protoNib means of registering with an NSCollectionView causes "theItem" to always be nil. 2) Using the class registry option, all works mostly fine. But if I remove the willDisplayItem and didEndDisplayingItem stubs, the system eats up gobs of memory on its first call to itemForRepresentedObjectAtIndexPath (with thousands of internal calls to these two stubs) and eventually crashes. Instruments shows *thousands* of 4k @autoreleasepool content items being created by AppKit. Any idea why this might be happening? (void)awakeFromNib { 		[self registerClass:[MECollectionViewItem class] forItemWithIdentifier:@"EntityItem"]; //	NSString *nibName = NSStringFromClass([MECollectionViewItem class]); //	NSNib *protoNib = [[NSNib alloc] initWithNibNamed:nibName bundle:nil]; //	[self registerNib:protoNib forItemWithIdentifier:@"EntityItem"]; 		 		__weak typeof(self) weakSelf = self; 		[self setDelegate:weakSelf]; 		[self setDataSource:weakSelf]; 		... } (MECollectionViewItem *)collectionView:(NSCollectionView *)collectionView 		 itemForRepresentedObjectAtIndexPath:(NSIndexPath *)indexPath; { 				MECollectionViewItem *theItem = [self makeItemWithIdentifier:@"EntityItem" 																												forIndexPath:indexPath]; 				return theItem; } (void)collectionView:(NSCollectionView *)collectionView 			willDisplayItem:(NSCollectionViewItem *)item forRepresentedObjectAtIndexPath:(NSIndexPath *)indexPath { } (void)collectionView:(NSCollectionView *)collectionView didEndDisplayingItem:(nonnull NSCollectionViewItem *)item forRepresentedObjectAtIndexPath:(nonnull NSIndexPath *)indexPath { }

The legacy NSCollectionView grid has some really simple behaviour when dragging items around in the grid. When dragging item(s) to a target location, the proposed drop location would animate slightly ("parting the Red Sea of adjacent items" as it were) for the proposed drop. A bonus: there wasn't a vertical insertion bar. I would assume that behind the scenes in the legacy implementation, the NSSpringLoadingDestination protocol and the view's animator instance were used to make this happen.. I managed to partly mimic this behaviour with the new NSCollectionViewGridLayout (via the aforementioned protocol/animator) and it's almost working. But I'm giving up on my approach as I can't see a means to obscure the blue vertical insertion bar right through the center of my items. That happens during my drag session when I propose at NSCollectionViewDropBefore operation (in my validate drop method) while returning anything but NSDragOperationNone. I do see that there's a layoutAttributesForInterItemGapBeforeIndexPath method on the new layouts; that might work, but I don't see any means to avoiding the insertion bar highlight. Does anyone know how to easily get this legacy behaviour with the post-OS10.11 NSCollectionView API?